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1 

Introduction 


1.1  Identification 

This  document  is  the  final  technical  report  for  the  project  Experience  with  Adaptive  Security 
Policies  completed  under  contract  number  F30602-96-0210  for  Rome  Laboratory.  The  objective 
of  this  work  was  to  extend  the  work  done  on  the  project  Experimentation  with  Adaptive  Security 
Policies  under  contract  F30602-95-C-0047.  In  particular,  the  scope  of  the  current  project  was 
to  assess  the  following  four  items: 

■  the  impact  on  system  assurance  of  switching  between  policies, 

■  the  usefulness  of  auditing  in  the  switching/recovery  process, 

■  tools  to  fachitate  construction  of  security  databases,  and 

■  trade-offs  regarding  mechanisms  for  adapting  policies. 

This  document  is  structured  to  present  the  results,  conclusions  and  lessons  learned  from  these 
evaluations.  Experimentation  with  adaptive  security  policies  for  the  current  work  was  per¬ 
formed  using  the  Distributed  Trusted  Operating  System  (DTOS).  Since  the  work  on  these  four 
tasks  proceeded  independently,  the  four  sections  of  this  document  dealing  with  each  task  may 
also  be  read  independently. 

1 .2  Experience  with  Adaptive  Security  Policies 

As  in  [22],  the  appropriate  place  to  begin  is  with  the  Orange  Book  definition  of  a  security  pohcy. 
the  set  of  laws,  rules,  and  practices  that  regulate  how  an  organization  manages,  protects,  and 
distributes  sensitive  information.  [  17]  When  an  organization  employs  an  automated  information 
system  (AIS),  the  security  policy  for  the  AIS  is  an  extension  of  the  organization’s  secunty  policy. 
Since  many  organizations  work  in  a  changing  security  environment,  an  organization  s  securitj' 
policy,  and  hence  the  security  pohcy  that  apphes  to  any  AIS  deployed  by  that  organization,  must 
be  adaptive.  The  goal  of  this  work  is  to  gain  additional  insight  into  the  details  of  implementing 
and  assuring  an  AJS  with  an  adaptive  security  pohcy. 

Section  2  describes  the  impact  that  the  loss  of  tranquihty  assumptions  has  on  formal  assurance 
for  an  AIS  with  an  adaptive  security  pohcy.  Typically,  static  security  pohcies  are  built  upon  a 
set  of  tranquihty  assumptions;  it  is  assumed  or  exphdtly  stated  that  the  security  attributes  of 
system  entities  (e.g.  sensitivity  level),  or  the  rule  sets  that  define  the  access  rules  between  those 
entities  (e.g.  the  level  POSet),  do  not  change.  Since  the  very  goal  of  an  adaptive  security  pohcy 
objective  is  to  change  the  nature  of  the  access  rules  enforced  by  the  system,  it  is  a  necessary 
conclusion  that  some  tranquihty  assumptions  will  not  hold  through  a  pohcy  transition.  Sec¬ 
tion  2  hsts  a  number  of  scenarios  in  which  security  pohcies  might  need  to  be  adaptive.  It  ^so 
provides  a  description  of  a  number  of  security  mechanisms,  tranquihty  assumptions  that  might 
be  made  in  pohcies  for  systems  enforcing  those  mechanisms,  and  a  mapping  back  from  the  hst 
of  tranquihty  assumptions  to  the  scenarios  in  which  these  assumptions  might  not  hold.  One 
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topic  of  particular  interest  is  dynamic  lattices:  adaptive  security  jiolicies  enforcing  multi-level 
security  (MLS)  rules  in  whicli  one  does  not  assume  that  the  lattice  (level  POSet)  is  tranquil 
across  policy  transitions.  Section  2  proposes  the  use  of  a  concrete  representation  of  the  lattice 
structure  which  facilitates  the  insertion  of  new  nodes  into  a  lattice  or  for  collapsing  a  lattice. 
Along  with  dynamic  lattices,  a  High-Water  Mark  Confidentiality  Audit  Policy  is  defined  which 
would  aid  in  analyzing  information  flow  following  a  period  of  relaxed  MLS  rules  (a  collapsed 
lattice). 

In  Section  2.6  there  is  a  description  of  the  changes  required  to  assure  a  system  with  an  adaptive 
security  policy  as  compared  to  a  system  with  a  static  poHcy.  Formal  assurance  tasks  include 
security  policy  modeling,  writing  specifications,  proving  the  model  wnH  the  specifications  are 
consistent,  conducting  analyses  for  covert  channels,  and  verifying  the  correspondence  between 
the  specifications  and  code.  Section  2.6  describes  the  additional  burden  for  assurance  tasks  at  a 
general  level  for  any  adaptive  policy  and  at  a  detailed  level  for  the  DTOS  medical  demonstration 
[23]  which  was  modified  to  include  a  second  security  policy  for  the  sake  of  this  discussion. 

Audit  data  is  often  cited  as  a  useful  source  of  information  about  events  which  occur  during 
periods  of  relaxed  security.  Section  3  presents  the  results  of  a  study  of  the  usefulness  of  audit 
data  for  system  administrators  recovering  fix>m  a  period  of  relaxed  security.  One  of  the  main 
problems  with  audit  data  is  that  it  is  collected  at  such  a  fine  level  of  granularity,  usually  for 
individual  permission  checks,  that  little  useful  information  about  the  high-level  flow  of  infor¬ 
mation  can  be  extracted  finm  it.  One  solution  proposed  in  Section  3,  implemented  for 
this  contract,  builds  on  the  existing  inter-process  communication  (IPC)  protocols  by  applying  a 
tracing  identifier  (TID)  to  each  message  passed  through  the  system.  The  TID  can  be  appended 
to  audit  date  and  used  to  collect  individual  audit  events  according  to  the  thread  of  execution 
that  has  imtiated  them.  Another  common  problem  with  audit  date  for  client-server  architec¬ 
tures  is  that  many  of  the  security-critical  operations  are  performed  by  servers  other  than  the 
microkernel.  Smce  altering  each  server  to  audit  events  would  complicate  the  integration  of  new 
servers,  a  modification  to  the  microkernel  was  implemented  to  allow  the  microkernel  to  audit 
the  requests  made  of  other  servers.  Both  methods  for  enhancing  audit  date  were  evaluated  for 
their  ability  to  aid  a  site  recovering  fium  a  period  of  relaxed  security. 

Any  AIS  which  is  expected  to  enforce  a  security  policy  must  initialize  the  security  policy  fium 
a  database  that  it  can  read  and  interpret  Se^on  4  considers  the  use  of  tools  for  specifying 
security  databases  for  adaptive  security  policies.  In  particular,  with  an  adaptive  security  pohcy, 
there  are  two  or  more  policies  under  which  the  AIS  may  run,  and  therefore  it  is  necessary  to 
construct  two  or  more  databases  to  define  the  security  policy  after  each  transition  in  addition 
to  the  initial  definition.  It  is  already  a  difficult  task  to  relate  the  policy  specification  to  the 
oi:ganizational  policy,  and  maintaining  a  lai^e  database  using  only  a  text  editor  is  prone  to 
error.  Whth  an  adaptive  policy,  the  problem  is  complicated  by  the  necessity  of  managing  the 
information  that  must  change  firom  one  policy  to  the  next.  Section  4  explores  using  a  tool  with 
a  graphical  user  interface  (GUI)  to  spedfy  the  security  database,  describing  the  design  and 
implementation  of  a  GUI  tool  that  creates  security  databases  and  supports  the  use  of  policy 
adaptation  mechanisms. 

The  final  section.  Section  5,  compares  four  methods  for  implementing  adaptive  security  policies. 
The  implementations  are  evaluated  against  a  set  of  six  criteria.  One  criterion  is  the  range  and 
type  of  policy  transitions  that  the  mechanism  will  support;  this  is  referred  to  as  policy  flexibility. 
The  second  criterion  is  the  functional  flexibility,  the  effect  that  a  policy  transition  has  on  running 
applications  and  the  consequences  for  the  users  and  their  tasks.  The  remaining  criteria  include 
the  security,  assurability,  reliability,  and  performance.  The  intent  of  the  trade-ofif  study  is  not 
to  recommend  a  single  solution  for  all  implementations  of  adaptive  security  policies,  but  rather 
to  show  which  mechanisms  are  most  appropriate  for  a  given  application. 
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Although  the  four  major  sections  of  this  report  are  somewhat  independent  of  one  another,  the 
ultimate  goal  of  the  entire  work  is  to  take  adaptive  secruity  out  of  the  realm  of  theory  and  into 
the  realm  of  application.  Thus,  in  a  more  theoretical  work,  one  might  state  that  additional 
auditing  would  be  useful  in  an  AIS  with  an  adaptive  policy,  but  this  study  has  attempted 
to  analyze  specific  improvements  to  auditing  in  an  ertisting  system.  To  the  extent  that  the 
development  of  a  complete  adaptive  system  was  not  within  the  scope,  the  observ'ations  of  this 
report  remain  somewhat  speculative;  however,  it  is  hoped  that  such  observations  lead  to  more 
concrete  work  along  the  path  to  developing  adaptive  secure  systems. 


1 .3  Document  Overview 

The  report  is  structured  as  follows: 

■  Section  1,  Introduction,  provides  an  overview  of  the  document. 

■  Section  2,  Tranquility  Study,  studies  the  sensitivity  of  assurance  arguments  to  the  loss 
of  tranquility  assumptions. 

■  Section  3,  Audit,  investigates  the  usefulness  of  audit  data  for  recovery  finm  periods  of 
relaxed  security. 

■  Section  4,  Database  Tools,  explores  the  use  of  a  GUI  tool  for  specifying  the  securitj' 
databases  for  an  AIS  operating  with  an  adaptive  security  poHcy. 

■  Section  5,  Trade-off  Study,  compares  four  diflPerent  implementations  of  adaptive  security- 
using  six  criteria  to  evaluate  which  implementations  are  suitable  for  specific  scenarios 
reqiiiiing  adaptive  security  poUcies. 

■  Section  6,  Summary,  includes  a  summary  of  the  results  and  observations  of  the  project 
along  with  “lessons  learned”  and  suggestions  for  future  work. 

■  Appendix  A,  DTOS  Overview,  covers  the  background  necessary  to  understand  elements 
of  this  report  specifically  referring  to  the  DTOS  security  architecture. 
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Section  ^ 

Tranquility  Study 


2.1  Introduction 

The  goal  of  this  study  is  to  understand  the  sensitivity  of  assurance  evidence  to  the  loss  of 
tranquility  asstimptions. 

Assurance  evidence  provides  confidence  that  one  knows  precisely  what  happens,  with  respect 
to  security,  in  a  computer  system,  and  that  what  happ>ens  falls  within  the  bounds  of  a  -certain 
set  of  rules  nnd  requirements.  If  one  cannot  assume  tranquility  of  the  attributes  of  processes 
and  files  on  a  given  system,  or  if  the  rules  for  access  control  are  changing,  can  one  still  have 
confidence  about  the  security  of  the  system?  How  can  one  maintain  a  level  of  confidence  in  an 
AIS  if  common  tranquility  assumptions  are  removed?  Those  are  the  question  which  this  study 
intends  to  analyze. 


2.2  Overview  of  the  Tranquility  Study 

In  the  first  few  subsections,  in  Section  2.3,  this  study  takes  a  step  back  to  survey  the  funda¬ 
mental  issues  in  assuring  a  computer  system,  starting  with  a  statement  of  general  security 
objectives  for  computer  systems  whether  they  employ  adaptive  poUdes  or  not.  This  is  followed 
by  a  discussion  regarding  the  refinement  of  objectives  into  concrete  requirements  which  define 
who  the  authorized  users  are  and  what  the  authorized  actions  are  relative  to  an  organization’s 
security  needs  and  the  mechanisms  of  a  system.  Since  the  objectives  of  a  system  must  match 
those  of  the  organization,  the  final  subsection  of  the  introductory  material.  Section  2.3.4,  con¬ 
tains  a  listing  of  scenarios  which  require  adaptive  security  pohcies.  The  scenarios  are  divided 
into  six  general  categories:  release  and  dissemination,  roles  and  tasks,  selective  hardening, 
organizational  support,  and  change  of  operational  control. 

The  next  several  subsections  in  Section  2.4  contain  a  discussion  of  tmnquihty  issues,  giving  a 
definition  of  tranquility  and  stating  the  utility  of  tranquility  assumptions.  Some  of  the  common 
tranquility  assumptions  are  explored.  These  include  assumptions  for  systems  enforcing  m-ulti- 
level  security  (MLS)  controls,  type  and  domain  (or  role-based)  controls,  and  identity-based 
access  controls  (IBAC). 

Some  effort  was  expended  to  map  the  list  of  common  tranquility  assumptions  in  Section  2.4 
back  to  the  scenarios  listed  in  Section  2.3.4,  but  many  experienced  readers  may  simply  choose  to 
cVim  or  skip  these  sections  since  they  contain  background  material  familiar  to  many  people  in 
the  computer  security  community.  New  ground  is  broken  in  the  following  sections  on  changing 
and  enforcing  an  adaptive  poHcy  and  in  the  section  on  the  ramifications  of  non-tranquihty  for 
assurance  tasks. 

In  the  next  subsection.  Section  2.5,  this  report  focuses  on  changing  and  enforcing  an  adaptive 
poUcy,  considering  dynamic  lattices  and  presenting  a  concrete  approach  to  defining  a  security 
level  POSet  which  allows  for  insertion  of  dynamic  levels  (and  for  collapsing  levels)  as  required 
\inder  some  scenarios.  Moreover,  this  study  proposes  a  high-water  mark  confidentiality  audit 
policy  in  Section  2.5.3  which  could  accompany  the  use  of  dynamic  lattices.  This  type  of  con¬ 
fidentiality  pohcy  corresponds  to  a  low-water  mark  integrity  audit  policy  in  the  way  that  the 
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Biba  integrity  model  correspondd  to  the  Bell  and  LaPadula  confidentiality  model.  This  partic¬ 
ular  policy  defines  a  method  for  tracing  contamination  during  times  when  the  policy  is  relaxed, 
gi\’ing  administrators  useful  information  on  how  to  roll-back  to  more  restrictive  poHcies. 

Finally,  in  Section  2.6  this  report  presents  the  ramifications  of  non-tranquihty  for  specific 
assurance  tasks,  including  the  following  hst:  pohcy  modeling,  formal  specification,  proofs  and 
alignments  showing  that  the  specifications  are  consistent  with  the  policy  model,  and  covert 
channel  analysis.  The  general  discussion  is  specialized  to  a  specific  case  patterned  on  the 
DTOS  medical  demonstration  in  Section  2.6.5. 


2.3  Security  Objectives  &  Policies 

2.3.1  Security  Objectives 

\Mien  setting  out  to  write  a  security  policy  for  an  automated  information  system  (AIS),  whether 
the  pohcy  should  be  adaptive  or  not,  one  must  decide  on  the  objectives  of  the  pohcy.  As  stated 
in  [6]  the  most  general  objectives  for  an  automated  information  system  are  for  confidentiahty,  ' 
integrity,  and  availabihty. 

The  Confidentiality  Objective  Information  is  protected  from  improper  disclosure. 

The  Integrity  Objective  Data  has  at  ah  times  a  proper  physical  representation, 
is  a  proper  semantic  representation  of  information,  and  is  operated  upon  correctly 
by  authorized  users  and  information  processing  resources. 

The  Availability  Objective  Information  and  information  processing  resources 
both  remain  readily  accessible  to  their  authorized  users. 

One  might  also  choose  to  include  an  objective  for  accountabihty  as  weh.  An  accoimtabhity 
objective  might  require  that  ah  events  in  which  sensitive  information  is  observed  or  critical 
information  is  altered  shall  be  subject  to  auditing  and  that  audit  records  shah  be  tamper-proof 
The  Orange  Book  [5]  places  equal  emphasis  on  the  accountabihty  of  the  users  of  the  system 
and  on  the  mandatory  and  discretionary  access  controls.  While  accountabihty  is  an  important 
feature  of  a  system  with  an  adaptive  security  pohcy,  especiahy  when  rolling  back  permissions 
from  a  period  of  relaxed  seciuity,  in  this  pertion  of  the  report,  we  shah  concentrate  on  the 
aspects  of  assurance  which  are  separate  from  auditing. 

2.3.2  Security  Policy  Requirements 

A  security  pehcy  is  a  refinement  of  a  set  of  security  objectives  into  a  set  of  security  requirements. 
Since  security  objectives  wih  be  met  in  part  by  a  set  of  mechanisms  on  the  system,  security’ 
p)ohcy  requirements  must  be  written  to  utilize  those  mechanisms.  There  must  also  be  an 
argument  which  shows  that  the  security  pohcy  reqiiirements  taken  as  a  group  are  sufficient  to 
meet  the  seciurity  objectives. 

The  confidentiahty  objective  can  be  met  by  imposing  access  controls  such  as  MLS,  Type  En¬ 
forcement  [1],  and  IBAC.  These  satisfy  the  objectives  of  confidentiahty  and  integrity.  Access 
controls  address  confidentiahty  by  constraining  who  observes  data,  and  this  is  siifficient  unless 
one  also  is  concerned  about  covert  channels.  Access  control  is  also  sufficient  to  control  who 

^  In  some  sources  the  word  security  is  used  to  imply  tiiat  information  is  not  disclosed  improperly  This  sense  of  the 
word  is  too  narrow,  because  it  does  not  include  the  concept  of  protecting  resources  from  being  interfered  with.  If  one 
intends  to  prevent  unauthorized  disclosure  of  information,  then  confidentiality  describes  tbip  more  accurately. 
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modifies  data  on  the  system,  but  is  insufficient  to  insure  that  the  integrity  of  information  is 
maintained.  For  example,  Clark  &  Wilson  [7]  refer  to  business  transactions  as  being  well- 
formed  transactions,  e.g.  ledger  entries  in  a  double-entrj’  bookkeeping  system  have  to  keep 
the  books  in  balance.  Access  control  only  insures  that  the  integrity  of  system  information  is 
maintained  (or  lost)  through  the  actions  of  authorized  users. 

The  objectives  stated  thus  far  are  very  broad,  general  statements  about  security  objectives  and 
will  apply  to  many  situations  and  organizational  seoirity  objectives.  Thus,  to  be  useful  a  policy 
needs  to  be  refined  in  a  step-wise  fashion  so  that  the  pohcies  of  the  organization  deploying  a 
trusted  system  are  reflected  in  the  security  pohcy  that  the  system  is  designed  to  uphold.  The 
step-wise  refinement  depends  on  the  definition  of  who  is  authorized  to  observe  and  modify  data, 
and  the  set  of  mechanisms  used  to  enforce  them. 

For  example,  in  an  environment  in  the  national  security  establishment,  files  have  sensitivity 
labels  and  users  are  cleared  according  to  the  trust  afforded  them.  Therefore,  a  system  deployed 
in  this  environment  would  be  expected  to  apply  MLS  rules  to  access  control. 

This  suggests  that  in  practice  a  securify’  policy  is  not  necessarily  formulated  in  a  top-down 
method,  but  in  a  combination  of  top-down  and  bottom-up  steps  in  which  the  oi^anizational 
or  system-level  security  objectives  are  refined  into  lower-level  requirements  in  the  AIS  with 
the  mechanisms  for  enforcement  in  mind.  Therefore,  for  a  system  enforcing  MLS  rules,  the 
confidentiahty  policy  can  be  refined  into  a  reqiiirement  that  no  one  shall  observe  data  unless 
authorized  to  do  so  by  MLS  rules,  i.e.,  the  Bell  and  Lapadula’s  simple  security  rule. 

2.3.3  Adaptive  Security  Policies 

Since  the  security  policy  enforced  by  an  AIS  must  reflect  that  of  the  oi^ganization  deploying  the 
system,  the  security  policy  must  be  adaptive  in  the  sense  that  the  set  of  individuals  who  are 
authorized  to  observe  or  alter  information  may  be  time  dependent.  The  basic  objectives  of  the 
security  policy  have  not  changed,  but  the  rules  by  which  the  objectives  will  be  met  have,  and 
the  method  for  refining  the  objectives  into  concrete  requirements  has  changed  as  well. 

The  question  is  to  what  extent  are  you  able  to  meet  your  objectives  when  the  rules  defining 
authorization  change.  An  immediate  change  of  policy  suggests  that  if  individual  A  can  access 
item  B  \inder  one  scenario,  and  the  rules  change  so  that  A  is  not  authorized  to  access  B,  the 
system  should  no  longer  allow  A  to  access  B. 

However,  there  may  be  circumstances  under  which  we  would  Mke  to  allow  A  to  have  access  to 
B,  even  though  they  are  officially  no  longer  authorized  to  do  so.  For  example  there  may  be  some 
critical  task  which  A  must  be  allowed  to  complete  even  with  the  change  of  policy.  If  the  system 
does  allow  A  access  to  B  after  the  rule  change,  there  should  be  a  period  of  timp  after  which 
access  is  denied.  In  such  situations  there  must  be  a  transitional  policy  which  allows  continued 
access. 

2.3.4  Scenarios  Requiring  Adaptive  Security  Policies 

The  following  subsections  and  itemizations  were  extracted  from  electronic  correspondence  be¬ 
tween  the  Institute  for  Defense  Analysis  and  Secure  Computing  [15]  regarding  adaptive  secu¬ 
rity  policies  in  the  “real  world.” 

2.3.4. 1  Release  and  Dissemination  The  release  and  dissemination  of  sensitive  mntprial  is 
often  time  dependent.  There  are  a  niimber  of  similar  scenarios  in  which  the  authority  to 
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observe  a  file  is  time  dependent. 

■  It  may  be  necessary  for  a  file,  which  a  party  is  not  allowed  to  observe  today,  to  be  released 
to  that  same  party  by  a  specific  time  tomorrow. 

■  Alliances  change  so  that  allies  with  whom  one  currently  shares  a  particular  form  of 
data  (e.g.,  image  data)  today  might  not  be  allowed  to  see  the  next  version  of  the  data. 

■  Different  rules  may  apply  for  operational  plans  between  the  time  when  one  is  planning 
the  operation  executing  it.  The  “need  to  know”  rules  change  between  the  two  stages 
of  planning  and  execution. 

Most  of  these  scenarios  depend  on  discretionary  access  control  enforced  throi^h  IBAC  policies 
and  access  control  lists.  An  adaptive  policy  meeting  the  needs  of  an  organization  under  the 
preceding  scenarios  would  need  to  have  time  dependent  access  control  hsts.  In  the  case  of 
operational  plans  to  which  access  is  more  highly  restricted  during  the  planning  phase,  there 
may  be  a  mode  change  fi^Dm  peacetime  to  crisis  which  triggers  the  change  in  the  ACL  making 
the  plans  more  widely  disseminated  for  those  who  need  to  execute  the  plans. 

When  a  document  is  subject  to  timed  release,  it  is  necessary  for  the  release  time  to  be  adjustable. 
Pohcies  for  systems  which  employ  timed  release  must  account  for  when  and  how  are  such 
releases  authorized,  authenticated,  and  executed.  Both  the  authorization  and  execution  may 
be  separate  operations  each  of  which  may  be  time  dependent. 

2. 3. 4.2  Roles/Tasks/Domains  It  is  a  common  scenario  that  two  or  more  people  will  be  respon¬ 
sible  for  carrying  out  the  duties  of  one,  role,  but  not  concurrently  (e.g.  Watch  Officer).  In  these 
cases  it  is  necessary  for  one  user  to  ha  nd  off  responsibilities  of  the  role  to  another  user.  If  the 
user  currently  acting  in  the  role  is  forced  to  log  out  before  his  successor  is  allowed  to  log  in, 
tranquihty  assumptions  may  still  hold. 

However,  there  be  cases  in  which  the  function  of  the  role  need  to  be  on-gomg,  without  inter¬ 
ruption.  In  such  a  case  there  should  be  a  mechanism  for  transferring  control  of  the  subjects 
operating  on  behalf  of  the  current  user  to  his  successor.  Possibly  an  additional  subject  would 
need  to  be  invoked  in  order  to  authenticate  the  identity  of  the  successor,  and  accompUsh  the 
transfer  of  authority  with  full  accountability  for  the  users  involved. 

A  complicating  factor  to  consider  is  when  the  two  users  involved  in  a  transfer  of  role  are  also 
authorized  to  other  roles.  For  example,  a  Watch  Officer  may  also  be  the  Chief  Engineer.  As 
Chief  Engineer  he  may  need  to  have  access  to  information  which  is  not  necessarily  available  to 
other  users  authorized  to  just  the  Watch  Officer  role.  If  a  user  is  authorized  to  multiple  roles,  the 
policy  must  account  for  whether  the  user  is  allowed  to  operate  in  several  roles  simultaneously 
or  whether  certain  tasks  authorized  to  some  roles  are  so  sensitive  that  the  user  operating  in 
that  role  is  not  allowed  to  be  acting  in  any  other  role  simultaneously.  This  would  comprise  the 
notion  of  “separation  of  duty.” 

Similarly,  a  user  acting  in  one  role  may  be  limited  in  his  actions  during  normal  operations,  but 
under  exceptional  circumstances  he  may  need  additional  authority  usually  reserved  for  a  user 
operating  in  another  role.  For  example  the  Command  Duty  (Dfficer  may  need  to  act  with  the 
authority  of  the  Commandiug  Officer.  This  authority,  while  delegated  to  the  Command  Duty 
(Dfficer  by  the  Commanding  (Dfficer,  can  only  be  invoked  under  specific  circumstances  and  any 
transition  in  the  system  which  allows  the  Command  Duty  (Dfficer  to  invoke  these  changes  must 
be  highly  regulated  and  audited  to  insure  accoimtabUity.  Some  of  the  caveats  in  the  preceding 
paragraph  apply  here  when  users  can  authorize  themselves  to  roles  with  greater  privileges. 
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2. 3. 4. 3  Selective  Hardening  A  nuinber  of  papers  on  adaptive  policies  have  assumed  that  in 
crisis  situations  that  security  constraints  may  be  relaxed  because  more  users  have  a  “need  to 
know  in  times  of  crisis  or  because  the  cost  of  losing  the  system  exceeds  the  cost  of  a  breach 
of  security.  However,  there  are  conditions  under  which  security  configurations  may  need  to  be 
“hardened”  as  defensive  conditions  change,  e.g.,  based  on  a  “DEFCON”  alert  or  an  anomalous 
event. 

Under  this  scenario,  a  policy  may  be  hardened  by  reducing  access  through  the  usual  access 
control  policies  such  as  mode  dependent  access  control  Usts  or  a  more  stringent  type  enforce¬ 
ment  pohcy.  A  policy  could  also  be  hardened  by  using  a  larger  level  POSet  during  the  period  of 
selective  hardening  and  by  using  a  collapsed  security  lattice  during  normal  operation. 

A  pohcy  could  also  be  hardened  through  measures  other  tbnn  the  usual  access  control  mech¬ 
anisms  such  as  full  vs.  selective  auditing,  stronger  cryptography,  prioritized  resource  sharing, 
and  enabling  of  redundant  resources  and  protection  features. 


2. 3. 4. 4  Organizational  Support  A  task  force  is  typically  composed  of  units  from  several  or¬ 
ganizations.  The  units  comprising  the  task  force  must  come  together  in  a  time  constrained 
manner,  and  the  composition  of  the  task  force  may  change  when  either  some  units  discontinue 
participation  or  others  join  the  task  force.  Under  this  scenario,  the  management  of  the  security 
pohcy  becomes  an  issue  in  a  domain  where  there  may  be  httle  time  to  devote  to  security  con¬ 
cerns.  Only  a  pohcy  which  is  weh  planned  in  advance  of  operations  can  support  such  dynamic 
changes. 


2.3.4. 5  Change  of  Operational  Control  (CHOP)  A  unit  under  the  control  of  one  command 
may  be  reassigned  to  support  a  mission  under  the  command  of  another  organizational  unit. 
The  security  pohcy  of  that  unit  must  flexible  enough  to  be  reassigned  to  the  new  command 
in  a  seemless  fashion.  For  example,  an  AWACS  plane  flying  over  Bosnia,  may  be  suddenly 
tasked  to  support  a  NATO  maritime  interdiction  mission  with  the  Italian  wnd  U.S.  Navies  in 
the  Adriatic.  The  security  pohcy  for  the  AWACS  systems  must  accommodate  the  change  of 
operational  control.  Some  information  from  the  AWACS  plane  would  necessarily  be  shared 
with  the  new  command.  Currently,  there  are  no  fiihy  automated  forms  for  this  type  of  pohcy. 


2.4  Tranquility  Issues 
2.4.1  Definition  of  tranquility 

What  do  we  mean  by  tranquil?  Webster’s  Dictionary  defines^  it  to  be  “unvarying  in  aspect,”  and 
offers  “steady”  and  “stable”  as  synonyms.  For  the  sake  of  studying  security  pohdes  regarding 
the  confidentiahty  and  integrity  of  data,  we  define  a  relationship  between  entities,  say  A  and 
B,  on  the  system  to  be  tranquil  if  the  access  control  pohdes  state  that  the  accesses  permitted 
for  A  to  B  do  not  change. 


2.4.2  Utility  of  Tranquility  Assumptions 

Tranquihty’  is  assumed  in  a  security  pohcy  for  various  attributes  of  entities  or  for  the  relation¬ 
ships  between  attributes  for  the  sake  of  keeping  the  security  pohcy  both  strong  and  simple. 

^The  second  definition  from  Webster’s  Ninth  Collegiate  Dictionary. 
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To  state  tranquilitj-  of  an  attribute  such  as  the  sensitivity  label  as  a  system  reqinrement  is  a 
strong  requirement.  For  example,  for  MLS  mandatory  access  controls,  Part  II,  Section  5  of  the 
Orange  Book  [5],  states  that  “the  system  must  assure  that  the  desi^tions  associated 
sensitive  data  cannot  be  arbitrarily  changed,  since  this  could  permit  individuals  who  lack  the 
appropriate  authorization  to  access  sensitive  information.”  A  system  that  requires  te^qi^- 
ity  of  sensitivity  labels  assures  a  fortiori  that  this  particular  attribute  cannot  arbitrarily 
changed”  since  they  cannot  be  changed  at  ah.  Furthermore,  tranquihty  assuinptions  make  as¬ 
pects  of  the  policy  simpler,  because  the  AIS  intended  to  enforce  the  policy  is  easier  to  implement 
anrl  analyze,  and  hence  is  more  likely  to  meet  the  requirements  of  the  security  poHcy.  Thus, 
tranquihty  assumptions  ahow  one  to  state  some  security  requirements  more  strongly  and  ease 
assurance  tasks. 

The  problem  with  tranquility  assumptions  are  that  they  are  inflexible.  Furthermore,  they  do 
not  map  weh  to  many  common  scenarios  which  require  greater  flexibility.  As  stated  above,  it 
is  also  important  that  the  security  poUcy  enforced  by  an  AIS  model  the  security  pohcies  of  the 
organization. 


2.4.3  Common  Tranquility  Assumptions 

WTiere  do  we  ordinarily  assume  tranquility Basicahy,  entities  have  attributes,  and  accesses 
between  entities  are  ahowed  or  denied  based  on  those  attributes  and  a  set  of  rules  for  access 
control.  The  security  pohcy  is  defined  on  the  system  by  the  combination  of  attribute  assign¬ 
ments  (labehng  of  entities)  and  access  control  rules.  We  can  consider  three  types  of  access 
control:  MLS,  Type  Enforcement,  and  IBAC.  The  former  two  are  mandatory  access  control 
mcrViantemg  and  the  last  one  is  a  discretionary  access  control  mechanism.  How  these  policy 
permissions  are  enforced  is  another  matter. 

The  entities  on  a  system  consists  of  subjects  (programs  in  execution),  objects  (data  storage 
containers),  and  users.^  The  attributes  and  rule  sets  required  for  enforcing  each  type  of  policy 
are  summarized  in  Table  2-1. 


Table  2-1:  Attributes  and  Rule  Sets  for  Enforcing  Security  Policies 


MLS  Pohcies 

Type  Enforced 
Pohcies 

IBAC  Pohcies 

Subject 

Level 

Domain 

User  &  Group 

Object 

Level 

Type 

Access  Control 
List 

User 

Level(s) 

Role(s) 

Group(s) 

Rtile  Definition 

Level  POSet 

Type  Enforce¬ 
ment  Database 

Access  Control 
List  or  UNIX- 
hke  Protection 
Mechanisms 

^  Users  are  system  entities  that  internally  represent  individuals  who  use  the  system.  Attributes  assigned  to  users 
are  assumed  to  correspond  to  authorizations  granted  to  individuals  Devices  could  be  considered  to  be  separate  entities, 
but  for  the  sake  of  simplicity,  devices  will  be  assumed  to  have  attributes  similar  to  objects.  For  example,  an  access 
control  list  for  a  device  would  define  the  set  of  users  and  groups  who  may  access  a  device. 
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2.4.3. 1  Tranquility  and  MLS  Policies  Systems  used  in  national  security  typically  employ  hier¬ 
archical  levels  and  categories  for  defining  the  sensitirity  of  data  the  clearance  of  individuals 

to  access  that  data.  The  traditional  rules  for  Multilevel  Security  (MLS)  are  implemented  to 
prevent  users  with  low  clearances  from  observing  high-level  data  to  prevent  high-level 
data  from  being  passed  to  lower-level  containers  where  users  without  adequate  clearance  may 
see  it. 

Since  subjects  operate  on  behalf  of  users,  it  is  necessary  to  assign  levels  to  subjects  as  well  as 
objects.  The  typical  rules  for  enforcing  an  MLS  policy  at  the  level  of  subjects  and  objects  are  the 
Bell  and  LaPadula  simple  security  and  *-properties.  However,  it  is  generally  necessary  to  relax 
these  rules  somewhat  to  allow  certain  subjects  to  write  information  down  in  level  (downgrade). 
Trusted  p>ermissions  such  as  this  may  be  granted  through  a  number  of  means  either  through  a 
relatively  flexible  mechanism  such  as  a  type  enforcement  or  less  so  by  hardcoding  permissions 
for  subjects  which  run  with  fixed  identifiers.  Most  systems  have  a  notion  of  downgrade  privilege 
since  the  strict  adherence  to  the  simple  security  and  *properties  limit  the  utility  of  the  system. 

For  an  MLS  system,  typical  tranqutbty  assumptions  include  that  the  level  assigned  to  each 
subject  and  object  is  tranquil  for  the  duration  of  that  entity’s  existence.  Similarly,  one  might  as¬ 
sume  that  the  sets  (or  classes)  of  privileged  subjects  which  are  granted  jiermission  to  downgrade 
are  tranquil. 

For  a  non- tranquil  MLS  system,  we  may  allow  the  level  of  an  object  to  be  changed.  This  would 
be  a  violation  of  the  strict  Bell  and  LaPadula  rules  forbidding  no  write  down.  However,  sets 
of  permissions  in  a  tranquil  sj^tem  may  be  logically  equivalent.  For  example,  a  high-level 
subject  may  have  permission  to  downgrade  information  from  one  object  to  another  if  it  has  the 
following  three  permissions:  premission  to  create  a  low-level  object,  permission  to  read  data 
from  a  high-level  object,  and  permission  to  write  that  data  to  the  low-level  object.  The  task  of 
assuring  this  operation  is  probably  equivalent  to  assuring  the  operation  of  allowing  a  trusted 
subject  to  change  the  sensitivity  label  of  the  object.  This  may  have  other  minor  benefits,  say 
for  the  performance  of  the  system,  but  these  are  necessarily  secondary  to  the  strength  of  the 
assurance  of  the  operation 

Similarly,  for  a  non-tranquU  MLS  system,  we  may  allow  the  level  of  an  subject  to  change.  If 
a  subject  drops  in  level,  any  data  it  holds  in  local  memory  would  effectively  be  downgraded. 
Furthermore,  if  a  high-level  subject  can  drop  in  level,  then  to  enforce  the  *-property,  permissions 
to  read  high-level  data  which  the  subject  had  been  granted  prior  to  its  change  in  level  must 
be  invalidated  in  any  permission  caching  mechanisms.  Conversely,  if  a  low-level  subject 
be  raised  in  level,  permissions  to  write  data  to  low-level  objects  which  the  subject  had  been 
granted  prior  to  its  change  in  level  must  be  invalidated. 

Flushing  caches  of  permissions  might  be  handled  in  different  ways,  these  are  discussed  in 
[22].  However,  it  must  be  noted  that  there  are  tradeoffs  depending  on  whether  permissions  are 
recomputed  as  needed  or  all  at  once.  Furthermore,  one  may  wish  to  restrict  a  subjects  ability 
to  change  in  level  depending  on  which  objects  it  has  open  It  may  be  necessary  for  a  subject  to 
close  certain  objects  before  chnngnng  level. 

Systems  in  which  the  level  of  a  subject  is  not  tranquil  may  assign  a  set  of  allowable  levels 
to  that  subject.  Such  sets  could  be  represented  by  a  maximum  allowable  level,  a  minirmim 
allowable  level,  or  a  range  with  both  a  maximum  and  minimum  level. 

User  levels  are  usually  treated  somewhat  differently  than  subject  levels.  A  user  will  typically 
have  a  set  of  levels  associated  with  it  representing  the  set  of  levels  at  which  the  user  is  allowed 
to  operate.  Some  systems  also  record  the  current  level  at  which  a  logged  in  user  is  operating, 
and  the  user  may  change  the  level  at  which  he  operates  as  long  as  it  is  within  the  set  of 
allowable  levels.  Otherwise  the  user  may  have  subjects  operating  on  his  behalf  as  long  as  the 
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subjects  operate  at  a  level  which  is  within  the  allowed  range. 

^VTiether  a  specific  level  is  associated  with  a  user  at  any  given  time,  or  if  the  user  is  allowed 
to  have  subjects  operating  at  a  range  of  levels,  the  question  relative  to  MLS  rules  is  whether 
the  user  can  cause  information  to  flow  downward  in  level  either  through  his  own  actions  or 
through  subjects  at  his  disposal.  Generally  speaking,  we  have  to  assume  that  users  who  are 
cleared  to  observe  certain  levels  of  data  can  trusted  not  to  disclose  that  data.  So  even  if  a 
user  can  have  two  subjects  operating  at  diflferents  levels,  information  does  not  flow  downward 
without  passing  through  the  user  unless  it  is  already  allowed  through  existing  exceptions  to 
the  Bell  and  LaPadifla  rules. 

The  remaining  tranquility  assumption  in  an  MLS  policy  is  that  the  mechanism  (database  1  that 
define  the  access  permissions  allowed  between  entities,  namely  the  level  POSet,  is  tranquil. 
More  specifically,  the  set  of  levels  and  categories  is  fixed,  and  the  dominates  relation  w'hich 
defines  the  partial  ordering  is  also  fixed.  If  levels  are  represented  as  a  lattice,  this  means  that 
nodes  and  edges  on  the  lattice  are  not  removed  or  added,  and  no  set  of  nodes  can  be  collapsed 
into  a  single  node.  Note  that  chAnging  the  level  POSet  by  changing  the  dominates  relation 
efiectively  changes  the  level  of  objects.  Examples  in  which  the  level  POSet  fails  to  be  tranquil 
are  given  below. 

During  a  period  of  relaxed  security  (crisis),^  some  levels  could  be  collapsed  together,  e.g.,  SE¬ 
CRET  and  SENSITIVE  (see  Section  2.5.3).  During  a  crisis,  a  user  may  be  required  to  read 
a  file  normally  unavailable  to  him;  the  insertion  of  new  levels  for  the  file  and  user  may  be 
required  (see  Section  2.5.2  and  [13]).  Collapsing  levels  is  logically  complementary  to  inserting 
levels.  Instead  of  inserting  new  levels  and  relabeling  a  file,  fium  If  to  and  granting  a  higher 
clearance,  fium  k  to  to  a  user  who  needs  to  read  that  file  during  a  crisis,  those  labels  and 
clearances  could  be  pre-loaded.  During  normal  operations,  those  pre-defined  levels  could  be 
coUapsed:  with  and  Ij  with  Ij. 

One  question  remains  when  considering  changes  to  the  level  POSet  and  that  is  how  levels 
represented  on  an  AIS  map  to  levels  defined  in  the  world  external  to  the  machine.  This,  of 
course,  is  highly  dependent  upon  the  policy  which  the  AIS  is  intended  to  implement. 


2.4. 3.2  Tranquility  and  Type  Enforced  Policies  At  the  most  basic  level  Type  Enforcement  simply 
assigns  another  attribute  to  each  subject  and  object  on  a  system.  Each  type  of  access  that  a 
subject  requests  for  a  given  object  is  allowed  or  denied  based  on  a  comparison  of  the  domain  and 
type,  and  each  type  of  access  that  a  subject  requests  for  another  subject  is  allowed  or  denied 
based  on  a  comparison  of  the  domains  for  the  requesting  subject  and  the  target  subject.  That 
is  for  every  ordered  pair  of  domain  and  type,  there  is  a  set  of  permissions  (e.g.,  a  subset  of 
[read,  write,  execute,  create,  destroy))  which  are  the  accesses  allowed  for  a  subject  operating 
in  that  domain  to  any  object  of  that  type.  Thus,  all  subjectiobject  and  subjectisubject  accesses 
are  limited  to  a  set  consistent  with  the  tasks  which  the  subjects  are  designed  to  perform.  This 
type  of  task-based  access  control  mechanism  is  perfectly  suited  to  enforcing  least  privilege. 

Furthermore,  since  executable  code  is  assigned  a  type  and  typically  there  is  a  one-to-one 
correspondence  between  domains  and  executable  code,  only  one  specific  type  of  process  may 
operate  within  a  given  domain  This  implies  that  Type  Enforcement  provides  a  mechanism 
which  not  only  restricts  which  subjects  have  access  to  objects  but  a  mpphnnigm  by  which  one 
assures  that  subjects  perform  only  those  transformations  of  data  which  are  intended. 

Each  user  is  assigned  a  set  of  domains  in  which  he  is  allowed  to  have  subjects  operating.  Since 
these  domains  define  a  set  of  tasks  that  the  user  can  perform,  a  set  of  domains  is  referred  to 
as  a  TX)le  for  the  user.  Thus  at  the  user-level,  type  enforcement  is  a  role-based  access  control 
mechanism. 
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For  a  type  enforced  system,  typical  tranquilitj’  assumptions  include  the  assumptions  that 
the  domain  of  a  subject  is  tranquil,  that  the  type  of  an  object  is  tranquil,  and  that  the  type 
enforcement  databases  will  not  change. 

As  for  roles  assigned  to  a  user,  there  might  be  tranquiLit>~  assumptions  at  several  levels.  The 
most  restrictive  assumption  would  hold  that  the  set  of  roles  assigned  to  a  user  is  tranq\iil. 
However,  just  as  for  the  clearance  levels  assigned  to  a  user,  the  roles  of  a  user  might  be 
changed  by  a  system  administrator.  We  could  characterize  this  as  “tranquil  except  for  system 
administratjon." 

For  a  non-tranquil  system,  we  may  allow  either  the  typ)e  or  domain  of  an  object  or  subject  to 
change,  we  may  enforce  a  different  type  enforcement  table,  or  we  might  allow  a  user  to  change 
roles  during  an  active  session.  Whereas  in  the  MLS  case  loss  of  tranquilitj’  assumptions 
have  clear  implications  relative  to  the  Bell  and  LaPadula  rules,  the  goals  of  type  enforcement 
are  to  enforce  least  privilege  and  separation  of  duty.  These  goals  are  less  concrete  than  the 
confidentiality’  goals  represented  by  an  MLS  policy. 

However,  since  type  enforcement  policies  are  a  task -based  policy  at  the  level  of  subjects  and 
objects,  reasons  for  allowing  non-tranquility  are  clear.  An  object’s  type  could  be  changed  if  the 
data  in  the  object  were  needed  to  perform  tasks  which  have  been  assigned  to  subjects  in  distinct 
domains,  or  if  the  data  needed  to  be  processed  in  a  number  of  steps  by  separate  subjects  in  a 
“trusted  pipeline  "  A  subject’s  domain  could  be  changed  because  it  needs  to  perform  a  sequence 
of  tasks  as  a  “trusted  procedxire.”  The  goal  in  this  case  would  be  to  grant  a  minimal  set  of 
permissions  to  the  subject  for  each  task  in  the  sequence. 

The  former  example  can  be  handled  in  a  system  with  tranquil  types  where  one  subject  can  read 
an  object  of  one  ty^e  and  write  that  information  into  an  obj^  of  another  (this  is  analogous  to  the 
effective  downgrade  mentioned  in  the  previous  subsection).  The  latter  cannot  be  accomplished 
in  a  system  with  tranquil  domains  and  potentially  could  be  very  useful  especially  when  a 
subject  is  required  to  perform  an  action  which  is  very  sensitive  and  requires  a  change  to  a 
domain  which  might  be  highly  privileged.  Again,  for  non-tranquil  type-enforced  systems,  as 
for  non-tranquil  MLS  policies,  permission  caches  must  be  flushed  to  prevent  information  finm 
flowing  through  a  subject  which  has  changed  domains. 

Just  as  the  POSet  may  change  for  a  non-tranquil  MLS  policy,  the  type  enforcement  databases 
which  contain  the  access  privileges  between  domains  and  types  or  between  two  domains  may 
change.  For  example  a  domain  may  be  given  a  larger  (or  smaller)  set  of  types  to  access  in  order 
to  accomplish  a  wider  (more  constrained)  set  of  tasks.  Similarly,  a  domain  may  be  granted 
more  permissions  to  a  type  to  which  it  was  already  granted  access.  For  example,  during  a 
period  of  crisis,  downgrade  privileges  could  be  given  to  a  domain  in  addition  to  normal  write 
permission  Opening  up  a  type  enforcement  database  by  adding  downgrades  could  be  an 
alternative  to  collapsing  levels  which  allows  a  finer  granularity  of  control  over  how  information 
can  be  disclosed  during  periods  of  relaxed  security.  As  with  previous  examples,  permission 
caches  woiild  need  to  be  flushed  when  permissions  have  been  revoked  due  to  a  policy  change. 

On  LOCK  [18],  a  role  consists  of  a  list  of  domains  in  which  any  user  who  is  authorized  to  that 
role  may  have  subjects  operating.  While  there  is  no  table  listing  each  role  and  its  set  of  domains 
on  LOCK,  the  concept  of  a  role  table  which  maps  a  role  name  to  a  set  of  domains  is  a  convenient 
construct.  The  piirpose  of  imposing  roles  on  users  is  to  provide  separation  of  duty  and  least 
privilege  at  the  level  of  the  system  users  rather  than  at  the  level  of  subjects  or  domains. 

It  is  probably  not  reasonable  to  assume  that  a  user  cannot  change  roles  or  that  the  set  of  roles 
to  which  a  user  is  authorized  in  tranquil.  However,  it  might  be  useful  to  assume,  for  the  sake 
of  separation  of  duty,  that  a  user  cannot  change  roles  \inless  all  subjects  associated  with  tasks 
in  one  role  are  terminated.  This  is  a  higher  level  of  control  required  than  for  permission  cache 
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flushing  for  domain  and  level  changes  for  subjects. 

If  the  set  of  domains  in  a  role  changes,  then  the  same  problems  occur  as  in  the  previous  case 
in  which  permissions  are  added  to  or  removed  finm  domains,  but  it  occurs  again,  as  in  the 
previous  paragraph,  at  the  level  of  users  rather  than  subjects.  It  may  be  necessary  for  a  user 
to  terminate  all  subjects  ojjeratLng  in  domains  to  which  he  is  no  longer  authorized. 


2. 4.3.3  Tranquility  and  IBAC  Policies  The  tranquility  assumptions  for  IBAC  policies  are  some¬ 
what  different  finm  those  for  MLS  and  type  enforced  policies.  In  particular,  the  rules  by  which 
IBAC  policies  are  enforced  are  also  the  attributes  associated  with  each  object.  Furthermore, 
TRAC  policies  have  been  generally  applied  to  implement  discretionary  access  controls  rather 
fbnn  mandatory  controls  though  there  is  no  reason  why  they  cannot  be  used  for  mandatory 
controls.  That  is,  it  is  more  likely  to  be  the  case  that  the  Access  Control  Lists  (ACLs)  for  objects 
are  not  assumed  to  be  tranquil.  Hence  a  measure  of  non-tranquility  is  already  accepted  for 
IBAC  policies. 

However,  for  IBAC  policies  a  typical  tranquility  assumption  holds  that  the  user  and  group 
associated  with  a  subject  are  tranquil  For  IBAC  policies  which  enforce  mandatory  access 
control,  the  ACLs  associated  with  objects  would  be  tranquil  as  well. 

If  a  subject  can  be  transferred  from  one  tiser  to  another,  supposing  that  the  two  users  need  act 
in  the  same  role  but  need  to  hand-off  responsibilities  for  that  role,  then  the  subject  user  would 
not  be  tranquil.  However,  we  might  assume  that  the  two  users  belong  to  a  group  of  users  who 
would  be  fiilfilling  the  obligations  of  this  role,  and  group  restrictions  could  be  used  to  meet  role 
restrictions.  However,  whenever  a  subject  is  handed  off  from  one  user  to  another,  there  may  be 
problems  with  access  control  lists  on  the  user-level.  For  example  if  user  A  hands  off  subject  S 
to  user  B  and  A  has  discretionary  access  to  a  file  via  S  but  B  is  not  on  the  access  control  list, 
then  there  may  be  problems  in  carrying  out  the  hand-off  Either  we  need  to  ensure  that  S  must 
close  the  file  in  question  and  purge  its  local  memory  of  any  data  observed  in  the  file,  or  in  the 
case  of  write  permission,  the  ^es  must  simply  be  closed  before  hand-off  occurs. 

Considering  some  of  the  scenarios  discussed  in  Section  2.3.4,  an  adaptive  security  policy  might 
employ  non-tranquil  ACLs  which  are  either  time  or  mode  dependent.  For  example  there  may¬ 
be  one  ACL  for  peacetime  and  one  for  wartime,  or  one  for  normal  mode  and  one  for  crisis  mode. 


2.4.3.4  Other  Tranquility  Assumptions  Other  assumptions  about  tranquility  occur  at  lower 
levels  of  the  system  such  the  Memory  Management  Unit  (MMU).  In  this  case,  a  subject  can 
open  an  object  and  request  permission  to  read,  write,  etc.  On  some  systems,  once  the  permission 
vector  is  computed  and  entered  into  the  MMU,  that  access  may  not  change.  This  can  be  changed 
on  the  Mach  microkernel.  In  fact,  since  DTOS  is  based  on  Mach,  the  ASP  1  project  made  use 
of  the  DTOS  facility  for  flushing  cached  accesses  to  this  level  of  detail.  This  is  true  of  systems 
which  use  a  dientiserver  architecture  in  which  the  server  knows  the  contents  and  address  of 
each  file,  and  subject  must  make  calls  to  the  server  to  read  and  write  data. 

The  concept  of  a  Trusted  Path,  as  represented  in  the  Orange  Book  [5],  represents  a  tranquility 
assumption  of  sorts:  namely,  that  ‘Ihe  TCB  shall  support  a  trusted  communication  path  be¬ 
tween  itself  and  users  when  a  positive  ...connection  is  required.”  It  is  conceivable  that  certain 
utilities  which  are  designed  to  operate  in  trusted  path  mode  in  normal  operation  might  not 
necessarily  be  allowed  this  uninterruptible  connection  dtuing  a  crisis.  Or  in  cases  in  which 
defenses  must  be  hardened,  and  the  integrity  of  iiq)ut  or  output  is  considered  more  critical, 
utilities  could  be  designated  trusted  path  utilities  xinder  the  hardened  policy. 
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2.5  Changing  &  Enforcing  the  Security  Policy 

2.5.1  Changing  Security  Policies 

In  this  section  we  list  a  number  of  different  methods  for  rbnn^ng  the  security  pohcy  and 
enforcing  the  new  policy.  In  [22]  there  were  three  methods  for  changing  security  policies 
investigated.  We  repeat  these  here; 

■  Two  or  more  policies  may  be  incorporated  into  a  single  Security  Server.  The  policy  is 
changed  by  changing  the  definition  of  the  permissions  allowed  by  the  system.  This  can 
be  a  matter  of  providing  two  different  tables  for  computing  access  vectors. 

■  The  current  Security  Server  hands  off  the  capability  to  receive  access  control  requests  to 
another  Security  Server  which  defines  a  different  policy. 

■  An  external  agent  designates  a  different  port  from  which  a  different  Security  Server 
receives  access  control  requests. 

Logically,  what  occurs  in  each  of  these  three  methods  is  that  the  computation  of  access  vectors 
changes;  the  attributes  of  the  subjects  and  objects  in  the  system  have  gone  unchanged.  Changes 
that  can  be  implemented  in  this  way  include  collapsing  or  inserting  levels  in  an  MLS  system 
and  opening  up  or  closing  down  the  Type  Enforcement  database  to  be  less  or  more  restrictive. 

None  of  these  three  methods  seems  to  be  substantially  different  from  the  others  when  con¬ 
sidering  the  end  .  result:  we  have  changed  the  policy  definition  However,  from  an  assurance 
standpoint  the  three  methods  of  changing  the  policy  are  different  because  of  the  way  that  the 
transitions  can  be  handled.  What  matters  is  how  quickly  these  changes  are  implemented,  the 
degree  of  atomicity  of  the  changes,  and  how  these  changes  are  coordinated  in  the  system  across 
its  components. 

The  first  of  these  three  is  more  nearly  atomic,  but  it  is  also  monolithic  and  inflexible.  The  second 
and  third  are  multi-step  processes:  the  Security  Server  must  notify  others  that  the  policy  is 
changing,  transfer  control  to  the  new  server,  and  the  new  server  must  receive  authority  from 
the  old  one.  The  Security  Server  must  know  that  the  policy  has  been  transferred  and,  especially 
in  the  third  method,  that  it  has  been  transferred  to  the  right  server. 

In  order  to  compare  the  three  methods,  there  are  two  questions  that  must  be  smswered.  First 
of  all,  from  the  point  of  view  of  assuring  the  system,  how  do  you  know  with  emy  confidence  what 
policy  is  actually  being  enforced  by  the  system?  With  an  atomic  change  of  policy  and  immediate 
cache  flushing,  uncertainties  over  the  policy  enforced  during  transition  are  decreased,  if  not  non¬ 
existent.  However,  with  more  complicated  coordination  between  two  servers  or  with  delayed 
flushing  of  cached  permissions,  the  boundaries  between  two  policies  being  enforced  are  not 
cleanly  delineated. 

Secondly,  there  is  the  balance  between  functionality  and  security.  Does  the  functionality 
allowed  or  precluded  during  the  transition  between  policies  meet  the  needs  and  objectives  of 
the  organization  that  the  system  is  intended  to  serve?  For  example,  if  a  user  is  in  the  middle  of 
performing  a  task  when  the  policy  is  made  more  stringent,  the  user,  or  any  processes  operating 
on  his  behalf  may  no  longer  possess  the  permissions  required  to  complete  the  task.  Thus,  a 
task  may  be  unable  to  be  completed  if  the  new  policy  is  enforced  too  quickly.  Thus,  functionality 
has  been  sacrificed  for  the  sake  of  secmity.  If  completion  of  such  tesks  is  mission  critical,  then 
the  alternative,  in  which  security  is  sacrificed  for  functionahtj',  would  be  more  desirable.  Some 
of  these  trade-offs  are  described  in  greater  depth  in  Section  5. 
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2.5.2  Dynamic  Lattices 

Dynamic  lattices  are  described  in  [13]  and  [22].  The  idea  is  that  during  a  crisis  a  user  at 
level  k  may  need  to  see  a  file  at  level  Ij  even  if  does  not  dominate  Ij .  Duri^  a  period  of 
relaxed  security,  the  file  could  be  downgraded  to  /;  and  the  user  could  be  allowed  to  operate  at 
/'  where  does  dominate  1', .  However,  we  do  not  wish  to  downgrade  the  file  to  a  level  winch  is 
observable  by  users  who  were  preriously  unable  to  observe  it  (except  for  the  one  now  operating 
at  /(,).  Similarly,  we  do  not  wish  to  give  the  user  now  at  level  lu  access  to  a  whole  set  of  files 
that  he  was  previously  unable  to  see.  Thus  for  a  level  /  in  the  original  lattice,  /  is  dominated  bj 
if  and  only  if  I  is  dominated  by  .  and  /  dominates  I'j  if  and  only  if  I  dominates  Ij 

Consider  a  typical  lattice  structure  with  two  hierarchical  levels,  high  and  low  (H  and  I  ),  and 
two  compartments  (or  categories),  a  and  b,  as  represented  in  Figure  2-1. 


Figure  2-1:  A  typical  lattice  with  two  hierarchical  levels  and  two  compartments. 

Suppose  that  Ij  =  H.h  and  =  L.a.  Its  clear  from  the  lattice  in  Figure  2-2  that  it  is  not 
possible  to  insert  new  levels  appropriately  without  adding  more  compartments  even  if  you  add 
an  intermediate  hierarchical  level,  M.  The  level  /[,  must  include  the  compartment  a.  The  level 
I'j  must  include  no  more  than  the  compartment  ^  ^  must  be  M.a.b  which 

dominates  L.a.b  which  is  not  dominated  by  =  L.a.  If  /„  =  M .a,  then  I',  must  be  M  which  is 
dominated  by  H  which  does  not  dominate  Ij  =  H.b.  Therefore,  if  this  problem  is  to  be  solved,  it 
must  be  done  so  by  adding  compartments  as  in  Figure  2-3. 

By  adding  the  compartment  c  to  all  levels  which  are  not  dominated  by  ,  it  is  possible  then,  by 
not  giving  compartment  c  to  /„ ,  to  ensure  that  no  level  is  visible  to  unless  it  was  also  visible 
to  L  Note  that  in  Figure  2-3  that  the  intermediate  level  M  could  in  fact  be  eqiial  to  H. 

How  can  this  be  done  in  general?  By  assigning  a  number  to  each  node  in  the  lattice,  we  can 
make  the  number  play  the  role  of  c  as  in  the  previous  example.  We  number  the  eight  nodes  in 
Figure  2-1  from  1  to  8.  We  add  a  numerical  compartment  n,  1  <  n  <  8,  to  a  node  A  if  A  is  not 
dominated  by  the  node  associated  with  n.  By  adding  so  many  compartments,  the  choices  for  /[. 
and  I'j  become  more  numerous.  Whether  one  can  choose  these  in  a  unique  way  is  unclear. 

A  better,  more  flexible  way  of  creating  dynamic  lattices  would  be  to  use  the  POSet  nature  of 
the  lattice  structure  and  to  worry  less  about  hierarchical  levels  and  compartments.  The  entire 
structure  of  a  POSet  can  be  localized  to  each  node  where  it  is  only  necessary  to  describe  those 
nodes  immediately  above  or  below  in  the  lattice.  For  example,  at  node  A,  one  lists  which 
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H.a.b 


Figure  2-2;  Inserting  levels  can  cause  problems. 


H .  a  .  b .  c 


Figure  2-3;  Adding  compartments  makes  the  new  lattice  work. 

I 

nodes  immediately  dominate  A  and  which  are  immediately  dominated  by  A.  In  Figure  2-1,  L.a 
dominates  L  and  is  dominated  by  L.a.h  and  H.a.  Since  the  local  description  of  the  POSet  tells 
us  that  H.a.h  dominates  H.a  and  L.a.h  as  well,  we  have  by  transitivity  that  H.a.h  dominates  L.a 
as  well.  Note  that  by  listing  the  levels  above  and  below  that  the  description  is  redundant  and 
that  either  coliimn  alone  will  suffice  to  describe  the  lattice;  however,  it  can  be  useful  to  record 
both  sets  of  nodes  which  are  directly  above  or  below  a  given  node. 

Dynamic  levels  corild  be  inserted  by  specifying  new  levels  and  their  local  dominance  relations. 
Suppose  once  again  that  Ij  -  H.b  ajod  =  L.a.  The  level  must  dominate  Ij  and  .  The  level 
I'j  must  be  dominated  by  and  //  (as  seen  in  Figure  2-2).  However,  that  only  specifies  half 
of  the  local  description.  What  remains  to  be  determined  are  the  levels  dominated  by  1',  and 
levels  that  dominate  The  requirement  is  that  any  level  that  dominates  and  //  must  still 
dominate  ,  and  that  any  level  dominated  by  /„  and  ij  must  stiU  be  dominated  by  Thus  at  /' 
the  levels  above  must  include  (be  equal  to)  the  least  dominating  level  of /„  and  If  (in  this  case 
H.a.b) ,  and  at  I'j  the  levels  below  must  include  the  greatest  dominated  level  of and  Ij  (in  this 
case  L).  In  our  example.  Table  2-3  yields  the  same  result  as  Figure  2-3. 

Table  2-3,  in  fact,  does  not  take  full  advantage  of  the  local  structure  of  the  POSet.  Without  the 
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Node  Dominated  by 

Dominates 

H.a.b 

— 

H.a,  H.b.  L.a.b 

H.a 

H.a.b 

H.  L.a 

H.b 

H.a.b 

H,  L.b 

H 

H.a,  H.b 

L 

L.a.b 

H.a.b 

L.a.  L.b 

L.a 

H.a.  L.a.b 

L 

L.b 

H.b,  L.a.b 

L 

L 

H,  L.a,  L.b 

— 

Table  2-2;  Local  POSet  Structure  of  Figure  2-1 


Node 

Dominated  by 

Dominates 

IL 

H.a.b 

L.a,  /; 

A _ 

H.b,  /(, 

L 

Table  2-3:  Additional  Structure  for  and  I'j 


restrictions  placed  on  the  new  levels  by  compartments,  the  levels  and  I'j  could  be  one  and  the 
same  as  shown  in  Table  2-4. 


Node 

Dominated  by  Dominates 

H.b 

L.a 

Table  2-4:  Alternative  Structure  for  =  I'j 


If  one  is  inserting  levels,  then  one  might  want  to  maintain  consistent  local  descriptions  of 
levels  above  or  below,  but  since  the  local  description  including  both  is  redundant,  it  may  be 
unnecessary  to  insert  the  new  levels  into  the  descriptions  of  levels  above/below  for  the  old  levels 
as  long  as  the  mArhnnism  enforcing  the  MLS  rules  “knows”  how  to  read  the  level  database  and 
pen  account  for  the  lack  of  redundancy. 

Similarly,  one  might  also  collapse  security  levels  using  the  local  structure  of  the  POSet.  For 
example,  if  it  was  necessary  to  coUapse  the  hierarchical  levels  H  and  L  while  maintaining  the 
compartments  a  and  6,  the  local  POSet  structure  could  be  amended  so  that  any  two  nodes  in 
Figure  2-1  which  are  l«ing  collapsed  into  one  node  each  dominate  the  other.  For  example,  //.a 
dominates  L.a  and  is  dominated  by  L.a.  It  would  be  unnecessary  to  specify  all  other  relations 
which  are  true  in  the  collapsed  lattice  (e.g.,  L.a.h  dominates  H.a,  since  L.a.h  dominates  L.a  and 
L.a  dominates  H.a).  This  provides  conaderable  flexibility  in  collapsing  a  POSet,  though  any 
organization  collapsing  levels  woxild  need  to  consider  all  of  the  ramifications  of  collapsing  levels 
in  this  way. 

Thus,  the  local  structure  of  POSets  provides  a  fi-amework  that  is  highly  flexible.  However,  the 
lattices  and  the  local  POSet  structure  provide  mathematical  models  for  a  relation  on  a  set  of 
external  levels  as  well  as  internal  levels,  and  the  foremost  consideration  is  to  map  any  external 
levels  into  the  internal  levels  for  an  AIS. 

As  an  alternative  to  the  two  methods  for  representing  dynamic  lattices  in  a  system  listed 
above,  one  might  use  MLS  and  type  enforcement  to  enforce  an  adaptive  security  policy  in 
which  a  domain  which  is  granted  read  and  write  privilege  in  the  more  restrictive  database 
could  be  granted  read  and  trusted  write  in  the  relaxed  database.  Thus,  while  a  file  could 
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be  downgraded  under  tbe  relaxed  j)olicj’,  type  enforcement  provides  a  finer  granularity  of 
mandatory  access  control  than  MLS  alone,  and  access  t'"-  downgraded  objects  would  still  be 
subject  to  access  controls  based  on  task  or  role  considerr  "ons.  Downgraded  files  could  not  be 
observed  by  arbitrary  users  simply  because  they  were  cleared  to  view  them 


2.5.3  A  High-Water  Mark  Confidentiality  Audit  Policy 

According  to  [6],  there  are  six  variations  of  the  Biba  Integrity  Model:  the  Low- Water  Mark 
Policy,  the  Low-Water  Mark  Policy  for  Objects,  the  Low-Water  Mark  Integrity  Audit  Policy, 
the  Ring  Policy,  the  Strict  Integrity  Policy,  and  the  Discretionary  Integrity  Policy  (a  specific 
proposal  for  the  Multics  system).  The  first  five  of  these  are  described  in  detail  in  [6].  The  most 
commonly  addressed  variation  of  the  six  policies  is  the  Strict  Integrity  Policy  which  is  dual  to 
the  Bell  and  LaPadula  model  for  confidentiality.  This  paper  introduces  a  policy  which  might 
be  useful  for  addressmg  concerns  about  confidentiality  when  recovering  fiom  a  relaxation  of 
security  policies  which  is  dual  to  the  Low-Water  Mark  Integrity  Audit  Policy.  This  new  model 
shall  be  referred  to  as  the  High-Water  Mark  Confidentiality  Audit  Policy. 

\Miereas  the  Strict  Integrity  Policy  provides  a  measure  of  integrity  for  subjects  objects, 
the  Low-Water  Mark  Integrity  Audit  Policy  provides  a  measure  of  contamination.  WTienever  a 
subject  observes  an  object  at  a  lower  contamination  level,  the  contamination  level  of  the  subject 
is  lowered  to  match  that  of  the  object,  unless  the  contamination  level  of  the  subject  was  alreadv 
less  than  or  equal  to  the  contamination  level  of  the  object.  Similarly,  when  a  subject  modifies 
an  object  at  a  higher  integrity  level,  the  integrity  level  of  the  object  is  lowered  to  match  that  of 
the  subject  unless  the  contamination  level  of  the  object  was  already  less  than  or  equal  to  the 
contamination  level  of  the  subject. 

For  a  High- Water  Mark  Confidentiality  Audit  Policy,  instead  of  the  assigning  a  new  set  of  levels 
of  contamination  for  subjects  and  objects,  the  policy  would  assign  a  second  sensitivity  label 
from  the  existing  set  of  sensitivity  levels  used  for  enforcing  MLS  policies.  Initially,  subjects 
and  objects  would  be  Eissigned  contamination  levels  equal  to  their  sensitivity  levels. 

H  security  levels  are  collapsed  dxiring  a  period  of  policy  relaxation,  a  subject  which  was  orig¬ 
inally  at  the  secret  level  might  read  an  object  wMch  was  originally  classified  as  top  secret. 
Since  the  level  POSet  has  been  collapsed,  the  system  would  not  deny  the  subject  access  to  the 
object;  however,  as  a  result,  the  contamination  level  of  the  subject  would  be  raised  to  top  secret. 
Similarly,  if  a  (formerly)  top  secret  subject  modifies  a  secret  object,  the  contamination  level  of 
the  secret  object  would  be  raised  to  top  secret  to  match  that  of  the  subject. 

Thus,  after  a  period  of  security  relaxation,  there  may  be  a  number  of  objects  and  subjects  which 
have  contamination  labels  wtoch  do  not  correspond  to  their  sensitivity  labels.  By  determining 
which  subjects  and  objects  fall  into  this  category,  one  can  then  assess  the  level  of  contamination 
incurred  by  lower-level  objects  and  subjects  while  security  was  relaxed. 

Beyond  the  possibility  of  merely  auditing  the  information,  when  the  period  of  relaxed  security  is 
over  and  it  is  necessary  to  roll-back  to  more  strict  controls,  it  might  eiIso  be  possible  to  reclassify 
subjects  and  objects  to  levels  appropriate  for  their  level  of  contamination.  For  example,  any 
object  which  was  at  one  time  labeled  secret,  but  was  contaminated  to  the  level  of  top  secret 
in  the  interim,  would  be  reclassified  as  a  top  secret  object  upon  rpU-back.  Objects  which 
have  been  raised  in  level  at  roll-back,  but  were  not  contaminated  during  the  relaxed  policy 
could  subsequently  be  reclassified  to  their  original  levels  after  examination  by  an  authorized 
individual. 
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2.6  Ramification  of  Non-Tranquility  for  Assurance  Tasks 

In  this  section  we  offer  some  general  comments  on  the  impact  of  an  adaptive  secmity  policy  to 
specific  assurance  tasks.  These  tasks  include  the  following; 

■  Policy  Modeling 

■  Formal  Specification 

■  Constructing  Proofs  that  the  Policy  is  Satisfied 

■  Spec-to-Code  Analysis 

■  Covert  Channel  Analysis 

While  some  of  the  information  in  this  section  app>ears  in  earlier  sections  of  this  report,  we  repeat 
it  here  to  emphasiae  the  impact  on  the  assurance  of  systems  which  do  not  assume  tranquihty. 


2.6.1  Policy  mocteling 

As  stated  in  Section  2.4.2,  the  value  of  stating  security  poUcy  requirements  which  require 
tranquility  assumptions  is  that  the  policy  is  both  simple  and  strong. 

If  the  security  policy  will  be  formalized  in  a  specification  language  such  as  Z  [25]  or  PVS  [  19], 
requirements  which  explicitly  state  the  tranquility  assumptions  become  very  powerful  tools. 
Tranqvulity  assumptions  form  system  invariants.  Knowing  that  these  invariants  exist  make 
the  task  of  writing  a  consistent  set  of  security  requirements  easier. 

However,  the  restrictive  nature  of  tranquility  assumptions  limits  the  range  of  expressiveness  for 
security  policies.  This  limits  the  utility  of  writing  a  security  policy,  since  many  organizational 
policies  are  not  tranquil,  and  the  policy  written  for  the  AIS  must  map  to  the  policy  apphed  to 
the  organization  using  the  system. 

First  nnH  foremost  an  adaptive  security  policy  has  to  address  how  the  policy  itself  changes  over 
time.  For  attributes  which  are  allowed  to  change,  it  may  be  necessary  to  state  under  which 
conditions  they  may  change.  There  may  be  policy  statements  about  the  changing  of  policy  rules 
and  who  Or  what  may  effect  these  changes.  While  statements  in  which  tranquihty  assumptions 
are  expUcitly  stated  may  be  eliminated  fium  an  adaptive  pohcy,  it  is  not  clear  that  the  ntimber 
of  statements  would  decrease. 

Furthermore,  an  adaptive  pohcy  may  require  a  number  of  changes  which  make  the  pohcy 
inherently  more  difficult  to  write.  In  particular,  one  might  need  temp>oral  or  real-time  logic 
to  state  various  pohcy  requirements.  For  example,  a  pohcy  requirement  might  state  that 
a  permission  cache  is  flushed  eventually.  In  this  case,  temporal  logic  would  be  required  to 
express  the  pohcy  formally.  In  particular,  one  would  need  the  “eventuahy  operator”  to  state 
the  pohcy  correctly.  If  the  pohcy  requirement  held  that  the  permission  cache  would  be  flushed 
within  ten  seconds,  then  a  re^-time  logic  would  be  required.  Using  either  of  these  logics 
increases  the  level  of  difficulty  of  expressing  the  pohcy. 

Finally,  since  an  adaptive  security  pohcy  requires  greater  attention  to  the  timing  of  actions 
taken  by  various  system  components,  especially  d\iring  transitions,  the  pohcy  may  need  to 
address  a  finer  degree  of  atomicity.  While  step-wise  refinement  might  allow  one  to  manage 
greater  complexity  in  general,  by  increasing  the  granularity  of  detail  addressed  in  the  pohcy, 
the  pohcy  will  necessarily  become  longer  and  less  comprehensible  in  global  terms. 
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2.6.2  Formal  Specifications  and  Proofs 


To  attain  the  Al  level  of  evaluation  as  specified  in  the  Orange  Book  [5],  it  is  necessary  to 
formally  specify  the  TCB.  Furthermore,  the  Life-Cycle  Assurance  for  an  Al  system  requires 
that  evidence  is  provided  showing  that  this  formal  top-level  specification  (FTLS)  of  the  TCB 
corresponds  to  the  security  policy  model.  ^Tiile  writing  the  FTLS  and  proving  that  the  TCB 
meets  the  security  policy  requirements  based  on  the  I%LS  are  two  separate  tasks,  we  shall 
discuss  the  two  together  because  of  their  close  relation;  formal  proofs  are  not  required  without 
the  FTLS  and  vice  versa. 

The  FTLS  describes  the  actions  of  the  TCB.  Not  only  do  the  set  of  mechanisms  which  are 
implemented  to  enforce  a  p.bangi  ng  policy  make  the  act  of  specification  more  difficult,  the  degree 
to  which  one  models  certain  actions  on  the  system  as  atomic  may  need  to  be  readdressed.  For 
a  system  with  a  static  policy  it  may  be  acceptable  to  model  an  action  as  atomic  when  it  is  in 
fact  not  implemented  as  an  atomic  action  if  the  difference  is  not  visible  to  the  security  policy. 
However,  if  the  policy  can  change,  then  it  may  no  longer  be  acceptable  to  model  certain  actions 
atomically. 

Specifically,  there  are  issues  related  to  cache-flushing  as  described  briefly  in  Section  2.5.1 
and  in  more  detail  in  [22].  For  example,  if  the  policy  is  changed  and  cache-flushing  is  done 
immediately,  then  the  model  must  reflect  a  change  in  policy  as  an  atomic  action.  However,  if 
cache  flushing  is  done  with  some  delays,  the  FTLS  must  attempt  to  model  the  delayed  behavior 
of  the  system  accurately.  For  some  specification  languages  tffis  may  in  fact  be  impossible  to 
model  correctly.  The  temporal  coordination  of  components  of  the  system  is  clearly  more  difficiilt 
to  express  than  what  is  required  for  a  system  in  which  one  only  needs  to  show  that  certain  rules 
are  satisfied  for  every  system  transition.  For  a  policy  which  can  be  expressed  using  real-time 
logic,  the  same  real-time  logic  coiild  be  used  to  write  formal  specifications  which  can  effectively 
describe  the  behavior  of  the  system  and  will  support  proofs  of  the  requirements,  but  this  still 
introduces  other  complexities. 

The  system  as  described  by  the  model  enforces  a  set  of  rules,  and  the  proofs  intend  to  show  that 
those  rules  match  the  rules  laid  down  by  the  policy.  Thus  in  particular  when  writing  proofs 
and  addressing  the  issue  of  cache-flushing,  assuming  that  the  ^LS  is  an  accurate  description 
of  the  TCB,  one  must  ask  whether  the  cache  represented  in  the  model  represents  the  security 
policy.  If  the  security  policy  clearly  states  how  policy  transitions  ought  to  be  handled,  and  the 
model  accurately  and  clearly  reflects  the  TCB  and  how  it  handles  cached  permissions,  proof 
eff  orts  may  be  straight-forward,  but  those  may  be  optimistic  assumptions. 

If  the  formal  policy  model  requires  temporal  logic,  then  so  do  the  proofs.  In  particular,  the  notion 
of  eventuality  (the  permission  cache  is  eventually  flushed)  poses  certain  difficulties.  First  of 
aU,  certain  “fairness”  assumptions  would  be  required  to  insure  that  whenever  the  system  has  a 
choice  about  processing  several  requests  (non-  determinism),  the  system  executes  each  request 
sometime  (i.e.,  “not  neveri).  Proof  rules  for  reasoning  with  eventuality  cau  be  tedious  to  apply. 

Since  an  adaptive  policy  may  actually  be  the  implementation  of  two  or  more  separate  policies, 
then  there  could  be  mffitiple  sets  of  proofs  for  each  separate  policy.  In  addition  to  the  separate 
sets  of  rules  enforced  by  each  policy,  there  would  also  be  proofs  showing  that  the  policy  changes 
were  correct.  For  a  set  of  n  policies,  it  may  be  the  case  that  one  set  of  proofs  for  each  policy 
and  one  set  of  correctness  proofs  for  aU  transitions  between  them  is  required.  However,  if  the 
correctness  arguments  for  transitions  depends  on  the  initial  and  final  rule  set  of  the  transition, 
there  would  be  n(n  -  1 )  transitions.  This  represents  a  substantial  increase  in  the  level  of  effort 
required  for  proofs. 
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2.6.3  Spec-toCode  Analysis 

^^Tien  the  actions  of  the  TCB  are  complicated  by  the  policy  enforcing  mechamsms  and  the 
coordination  of  the  components  in  the  system,  the  task  of  verifying  the  correspondence  of  the 
specifications  to  the  code  will  become  more  complicated  just  as  the  task  of  writing  specifications 
does. 

Furthermore,  as  discussed  in  the  previous  section,  the  compleidty  of  the  specifications  may 
depend  on  the  type  of  logic  required  to  specify’  the  system.  Systems  w^ch  require  temporal 
or  real-time  logics  for  specification  make  performing  spec-to-code  analysis  inherently  different 
fiom  the  analysis  performed  for  a  system  which  does  not.  Again,  the  issue  of  eventuahty’  and 
accompanying  fairness  assumptions  may  be  difficult  to  verify. 

2.6.4  Covert  Channel  Analysis 

There  are  two  approaches  for  performing  covert  channel  analyses:  formal  and  informal.  Formal 
methods  of  covert  channel  analysis  are  performed  when  the  security  policy  includes  includes 
statements  such  as  nondeducibihty  or  noninterference  security  (nondeducibihty  security  was 
introduced  by  Sutherland  in  [26]  and  non-interference  security  by  Gougen  and  Meseguer  in 
[11]).  Informal  methods  of  Covert  channel  analysis  may  employ  the  Shared  Resource  Matrix 
(SRM)  Methodology.  For  neither  informal  nor  formal  analyses  does  the  current  state  of  the  art 
encompass  adaptive  security  policies. 

The  current  experience  with  noninterference  analysis  has  been  restricted  to  deterministic 
systems  with  atomic  requests.  There  have  been  a  number  of  proposals  for  non-determioistic 
systems  but  little  practical  experience.  Experience  has  been  limited  to  fixed  policies.  At  this 
time,  there  is  really  no  theory  for  how  to  conduct  such  an  analysis  for  an  adaptive  security 
policy.  I 

As  for  informal  methods,  these  are  essentially  manual  procedures  which  are  error  prone.  The 
additional  subtleties  of  an  adaptive  policy  would  increase  the  likelihood  of  errors  creeping  into 
the  analysis.  Where  there  is  tool  support  for  conducting  informal  analyses,  the  policies  have 
been  assumed  to  be  static. 

The  basic  problem  with  which  either  method  must  struggle  is  the  definition  of  a  covert  channel 
for  an  AIS  with  an  adaptive  security  policy.  Generally  covert  channel  analyses  are  concerned 
with  MLS  pohcies  and  the  flow  of  information  downward  in  level.  For  policies  using  Type 
Enforcement,  a  covert  channel  is  a  little  different;  however,  we  are  simply  concerned  about 
client  subjects  being  able  to  observe  information  to  which  they  are  not  auffiorized  through  the 
security  pohcy,  whether  its  rules  are  determined  by  MLS  or  Type  Enforcement.  Thus,  a  covert 
rViPTinpt  in  the  context  of  Type  Enforcement  would  be  the  imintended  flow  of  information  across 
domains  by  authorized  operations. 

For  example,  suppose  that  an  AIS  is  operating  under  a  set  of  pohcy  rules  Pi  under  which 
a  subject  operating  in  domain  D\  modifies  an  object  of  type  T  using  operation  opi  and  that 
another  subject  operating  in  domain  D2  may  observe  an  object  of  type  T  using  operation  op2- 
Suppose  that  ops  is  the  operation  that  changes  the  security  pohcy  being  enforced  by  the  AIS 
from  pohcy  Pi  to  a  new  pohcy  P2  where  P2  disallows  the  flow  of  information  from  Di  to  D2. 
Then,  does  the  sequence  {opi ,  opz,  0P2)  represent  a  covert  channel?  Similarly,  if  op^  changes  the 
pohcy  from  P2  to  Pi,  does  the  sequence  {opi ,  op^,  0P2)  represent  a  covert  channel? 

Perhaps  the  point  of  view  of  individual  sets  of  pohcy  rules  Pi  and  Pj  are  simply  inadequate 
to  answer  the  Cfuestion,  and  what  is  reqiured  is  a  super-pohcy  which  declares  what  is  allowed 
or  denied  at  the  transitions  between  them.  For  example,  a  relaxed  super-pohcy  for  Pi  and  P2 
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might  say  that  any  information  flow  over  a  period  of  transition  from  the  relaxed  pohcy  Pi  to 
the  stricter  pohcy  P2  is  allowed.  Whereas,  a  stronger  super-pohcy  might  be  more  concerned 
with  contamination  (e.g.,  contamination  of  objects  of  type  T  by  subjects  in  domain  Di )  and  deny 
certain  types  of  information  flow  over  a  period  of  transition  from  the  relaxed  pohcy  Pi  to  the 
stricter  pohcy  Pj-  It  is  not  clear  what  extra  level  of  effort  is  required  for  creating  a  super-pohcy 
which  would  define  what  covert  channels  are  under  an  adaptive  p>ohcy. 


2.6.5  An  Example  Application 

A  stated  goal  of  this  report  is  to  analyze  and  test  an  apphcation  for  adherence  to  security 
requirements  during  a  pohcy  transition  period.  The  target  apphcation  is  the  DTOS  medic^ 
demonstration  which  is  described  in  fiih  detail  in  the  DTOS  Demonstration  Software  Design 
Document  [23].  The  DTOS  prototype  is  described  in  greater  detail  in  Appendix  A. 

The  medical  demonstration  consists  of  a  database  server  which  manages  a  set  of  patient  records. 
The  database  is  accessed  by  various  users  through  chent  subjects;  each  chent  operates  in 
a  domain  representing  the  users’  functions  as  physicians,  nurses,  administrators,  etc.  These 
chents  do  not  access  the  database  manager  directly  but  make  requests  for  information  through  a 
front  end.  The  front  end  in  turn  consults  the  DTOS  Security  Server  which  checks  permissions 
for  each  chent  to  various  aspects  of  a  patient  record.  The  conceptual  design  of  the  medical 
demonstration  is  hlustrated  in  Figure  2-4. 

The  point  of  the  original  demonstration  was  to  show  how  apphcations  could  be  built  on  top  of  the 
DTOS  platform,  and  using  the  feature  for  loading  (or  reloading)  the  security  pohcy,  permissions 
for  the  apphcation  could  be  added  to  the  existing  platform  permissions.  Since  another  set  of 
pohcy  permissions  can  be  loaded  at  any  time  without  restarting  the  system,  we  will  define  a 
second  set  of  permissions  and  discuss  the  ramifications  on  assurance  tasks  frxim  changing  fix)m 
one  set  of  permissions  to  the  other. 

The  comments  made  in  the  preceding  subsections  were  offered  as  a  general  discussion  of  the 
issues  faced  when  attempting  to  assure  a  system  with  an  adaptive  security  pohcy.  The  foUowing 
subsections  provide  a  concrete  system  which  has  an  adaptive  pohcy.  The  following  analysis 
paraUels  the  general  discussion,  but  specializes  it  to  this  particular  case. 

2.6.5.1  The  DTOS  Medical  Demonstration  As  shown  in  Figure  2-4  chent  tasks  send  requests 
to  manipulate  and/or  access  patient  data  to  the  Database  Server  via  the  messaging  mechanism 
in  Mach.  The  Demo  Exec  starts  up  the  Chent  and  Database  Server  tasks,  then  controls  the 
operations  of  the  demo  based  on  user  input. 

Each  patient  record  contains  three  types  of  information  as  illustrated  in  Figure  2-5:  adminis¬ 
tration,  billings  and  medical.  Each  kind  of  information  has  a  set  of  services  associated  with 
them. 

■  A  patient  record  can  be  created  and  deleted 

■  Admin  data  can  be  read  and  modified 

■  Billings  and  medical  data  (diagnosis  and  vital  signs)  can  be  read,  modified  and  appended. 

Access  to  these  services  are  determined  by  the  relationship  between  the  chent’s  security 
context"*  and  the  security  context  associated  with  the  Database  Server’s  service  port. 

*  On  DTOS  the  security  context  ie  the  set  of  attributes  of  a  subject  or  object  required  to  make  security  decisioiiE.  In 
the  DTOS  medical  demonetration  the  primarj’  attributee  are  the  domain  of  a  subject  and  the  type  of  an  object  for  a 
policy  employing  Type  Enforcement. 
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Figure  2-4;  Demonstration  System 


The  Database  Server  interacts  with  the  Name  Server  to  make  a  send  right  to  its  service  port 
accessible  to  potential  clients.  The  chents  obtain  a  send  right  to  communicate  with  the  Database 
Server  by  interacting  with  the  Name  Server. 

The  Database  Server  TCB  Extension  (TCB-E)  is  the  part  of  the  Database  Server  which  checks 
that  specific  chents  have  the  required  permission  to  the  service  operations  being  requested. 
This  part  of  the  Database  Server  is  run  in  a  separate  task  to  demonstrate  a  stronger  separation 
of  the  TCB  permission  checking  fium  the  larger  more  difficult  to  assure  body  of  software  tl^t 
may  make  up  a  real  Database  Server.  The  Database  Server  TCB  Extension  makes  its  service 
port  visible  to  all  potential  chents  via  the  Name  Server. 

The  Database  Server  Service  Processing  is  the  element  of  the  Database  Server  which  actually 
carries  out  the  service  requests  made  by  chents  indirectly  through  the  Database  Server  TCB 
Extension.  It  also  makes  its  service  port  visible  to  potential  chents  through  the  Name  Server. 

The  DTOS  Demonstration  chent  is  a  generic  chent  executable  that  is  instantiated  in  multiple 
tasks  in  specific  domains  representing  the  various  types  of  chents.  In  the  demo,  five  chent 
domains  are  implemented;  Admin,  Accounting,  Doctor,  Nurse  and  Insurance.  When  it  is  clear, 
we  refer  to  chents  and  domains  interchangeably.  For  example,  a  chent  task  whose  domain  is 
Admin,  is  generahy  referred  as  the  Admin  chent.  Each  chent  task’s  domain  determines  the 
kind  of  Database  Server  service  requests  it  is  ahowed  to  send  to  the  Database  Server  via  the 
TCB-E  service  port. 
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PATIENT  RECOR 


ADMIN 

NAME 

BIRTH  DATE 
ADDRESS 
ADMISSION  DATE 
ROOM^ 


BILLINGS 


TOTAL  BILL 

PAYMENT 

BALANCE 


MEDICAL 


VITAL  SIGNS 


DIAGNOSIS 

/°/+ 


Read  Service  Modify  Service  Append  Service 


Create  Service 


Figure  2-5;  A  Patient  Record 

2.6.5.1 .1  DTOS  Demonstration  Security  Policy  A  security  policy  for  the  DTOS  Demonstration 
must  define  the  security  contexts  associated  with  each  subject  and  object  used  in  the  system. 
The  policy  is  based  on  ^C’s  Type  Enforcement  security  policy.  The  original  database  security 
policy  for  the  DTOS  Demonstration  is  summarized  in  Table  2-5,  and  a  second  policy  is  summa-'^ 
rized  in  Table  2-6.  The  letters  indicate  the  services  that  the  domains  are  allowed  to  request 
through  the  database  request  port.  The  data  which  the  services  process  are  nlcn  shown  in  the 
columns.  The  append  permission  is  a  more  restrictive  form  of  the  modify  and  some  clients  may 
have  permission  to  the  former  but  not  the  latter. 

Under  both  policies,  medical  information  is  restricted  to  doctors  and  nurses,  billings  information 
to  accounting.  Under  Policy  1,  general  information  is  more  widely  available;  while  under 
Pohcy  2,  accounting  and  insurance  clients  are  no  longer  able  to  access  billing  and  administrative 
data  while  nurses  are  given  greater  permissions  to  create  records,  modify  administrative  data 
and  append  diagnoses.  ’ 

The  rationale  for  the  second  set  of  permissions  is  that  there  might  be  periods,  say  at  night¬ 
time  or  over  holidays,  when  normal  administrative  tasks  are  not  only  not  expected  to  be 
performed,  but  to  maintain  data  integrity,  no  access  to  these  portions  of  patient  records  is 
allowed.  Furthermore,  since  hospital  staff  may  be  reduced  over  these  periods,  greater  accesses 
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Table  2-5:  Accesses  to  Patient  Database  Services:  Policy  1 
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Table  2-6:  Accesses  to  Patient  Database  Services:  Policy  2 
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must  be  given  to  nursing  staff  who  might  be  in  relatively  greater  supply. 

Figure  2-6  shows  the  Admin  chent  making  successful  requests  to  create  a  record,  and  to  modify 
admin  data  while  the  Doctor  and  Insurance  cUents  requests  for  the  same  services  fail  due  to 
lack  of  permissions.  The  shaded  areas  in  the  access  vectors  indicate  p»ermissions  which  the 
chents  do  not  have,  but  are  shown  for  completeness. 

Figure  2-7  shows  another  example  of  service  controls  in  which  the  Nurse  chent  in  now  allowed 
to  append  diagnosis  data  which  could  only  be  done  by  the  Doctor  chent  under  Pohcy  1.  In 
addition,  the  Accounting  chent  fails  on  ah  requests,  even  on  the  request  to  modify’  billings  to 
which  it  has  access  under  Pohcy  1. 

2.6.5.2  Ramifications  for  Assurance  Tasks  In  the  foUowing  subsections,  we  will  echo  the  gen¬ 
eral  comments  made  in  Section  2.6  regarding  the  impact  of  non-tranquihty  on  specific  assurance 
tasks  providing  specific  comments  as  ahowed  by  the  example  apphcation. 

The  security  pohcy  for  this  specific  apphcation  is  relatively  simple.  The  objectives  of  the 
apphcation  are  to  release  portions  of  patient  records  only  to  those  people  who  have  a  need 
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Figure  2-6:  Service  Checks  for  Admin,  Doctor  and  Insurance  Clients  Under  Policy  1 


to  read  them  and  to  allow  a  controlled  group  of  people  access  to  create,  modify,  append,  or 
destroy  records.  It  must  be  assumed  that  users  and  client  subjects  which  have  access  to  modify 
records  will  act  appropriately.  Thus,  by  controlling  the  privilege  to  modify,  we  may  argue 
that  the  integrity  of  the  database  can  be  maintained.  Audit  records  can  be  used  to  provide 
accountability  for  inappropriate  modifications  of  data  records. 

As  discussed  in  Section  2.6,  the  effect  of  introducing  the  second  policy  for  the  application  de¬ 
pends  on  how  the  transition  between  the  two  policies  is  implemented.  For  this  application 
it  is  probably  acceptable  to  allow  for  some  delays  in  the  transition  between  Pohcy  1  and  Pol¬ 
icy  2;  however,  this  probably  has  the  greatest  effect  on  the  assurance  tasks.  Flushing  cached 
permissions  immediately  upon  the  change  of  policy  reduces  the  impact. 


2.6.5.2.1  Policy  Modeling  The  security  is  more  than  just  the  collection  of  tables  represented 
by  Figures  2-5  and  2-6.  Immediate  transitions  from  one  policy  to  the  other,  makes  the  pohcy 
for  the  transition  easier  to  model.  This  is  the  current  implementation.  As  previoxxsly  noted, 
DTOS  supports  a  mechanism  for  reloading  the  security  pohcy,  and  this  automaticallv  flushes 
all  cached  permissions.  ^ 

As  discussed  in  Section  2.6,  if  the  implementation  and  the  security  pohcy  ahow  for  the  transition 
to  occur  at  any  future  time  rather  than  immediately,  then  the  pohcy  would  have  to  modeled 
using  temporal  logic. 
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Figure  2-7;  Service  Checks  for  AccountLog,  Nurse  and  Doctor  Clients  Under  Policy  2 

2.6. 5.2.2  Specification  and  Proofs  There  are  a  small  number  of  components  to  this  applica¬ 
tion,  in  fact  the  specifications  for  this  example  could  be  limited  to  the  Database  Server  TCB 
Extension  anrl  a  generic  client  subject.  The  actions  of  the  Name  Server  and  to  some  extent  the 
Security  Server  could  be  abstracted  away. 

The  main  issue  is  whether  permission  caching  would  need  to  be  modeled.  Since  permissions 
are  flushed  immediately,  one  might  not  even  model  the  caching  of  permissions  and  model  the 
system  as  if  the  Database  Server  always  queried  the  Secvirity  Server  for  access  permissions. 
A  number  of  the  details  can  be  abstracted  away.  If  this  is  the  case,  then  the  specifications  are 
quite  simple,  perhaps  no  more  complicated  than  for  a  single  pohcy. 

However,  if  an  alternative  implementation  allowed  delays  in  cache  flushing,  then  not  only 
wovild  the  permission  cache  need  to  be  specified,  it  would  have  to  be  modeled  accurately  using 
a  temporal  or  real-time  logic. 


2.6.5.2.3  Spec-to-Code  Analysis  Again,  the  main  issue  for  spec-to-code  analysis  is  whether 
permission  caching  is  modeled.  If  the  specifications  are  simple  and  many  of  the  details  are 
abstracted  away  than  the  spec-to-code  analysis  would  also  be  relatively  simple.  F specifications 
are  written  using  a  temporal  or  real-time  logic,  then  the  spec-to-code  analysis  becomes  more 
complicated  commensurate  with  the  added  complexity  of  the  specifications. 


2.6.52  A  Covert  Channel  Analysis  The  pohcy  for  this  apphcation  does  not  support  MLS  access 
controls;  so  as  discussed  in  Section  2.6.4,  we  must  be  careful  to  state  what  a  covert  channel 
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is  in  this  context.  We  are  concerned  about  client  subjects  being  able  to  observe  information  to 
which  they  are  not  authorized  through  the  Type  Enforcement  policy,  and  we  must  define  what 
flow  of  information  across  domains  by  authorized  operations  ought  to  be  allowed  over  periods 
of  transition. 

In  the  case  of  the  policies  deflned  for  the  medical  example,  Policy  1  allows  the  Insurance 
client  to  read  administrative  records,  and  no  one  who  may  modify  the  administrative  records 
(Administrator  dients)  can  read  either  the  diagnosis  or  vital  signs.  However,  under  Policy  2, 
the  Nurse  chent  may  read  the  diagnosis  and  vital  signs  and  may  also  modify  the  administrative 
records.  The  potential  for  information  to  flow  from  the  diagnostic  information  to  the  domain 
for  the  Insurance  client  exists  when  the  policy  changes  from  Policy  2  to  Policy  1. 

If  the  super-policy  holds  that  the  Insurance  client  shall  have  no  access  to  diagnostic  informa¬ 
tion,  then  a  covert  channel  may  eidst.  Thus,  the  covert  channel  analysis  would  have  to  examine 
how  the  Nurse  chent  may  modify  the  administrative  records  and  the  rate  at  which  information 
may  flow  from  diagnostic  records  to  administrative  records.  Since  the  pohcy  transitions  would 
occur  at  long  intervals,  at  most  two  per  day,  the  capacity  for  this  channel  is  probably  very 
low,  especially  if  the  Nurse  chent  is  highly  constrained  in  the  ways  that  it  may  modify  the  ad¬ 
ministrative  records,  minimizing  the  number  of  characters  that  can  be  transmitted.  However, 
even  low-  bandwidth  could  have  potentially  devastating  results.  The  message  “John  Doe  has 
cancer’'  only  needs  to  be  sent  once  to  cause  great  harm.  As  with  many  other  security  and  safety 
apphcations,  some  events  are  unacceptable  even  if  their  likelihood  is  so  small  that  the  expected 
loss,  as  calculated  by  statisticians  and  actuaries,  seems  acceptable. 

2.7  Summary 

Section  2.4  surveyed  the  range  of  tranquhity  assumptions  that  one  can  make  in  formulating 
a  security  pohcy  and  their  utihty.  However,  in  order  to  provide  the  adaptive  secxirity  pohcies 
required  by  the  scenarios  described  in  Section  2.3.4,  a  number  of  these  tranquihty  assumptions 
must  be  discarded.  Section  2.4.3  discusses  these  specific  assiunptions  and  for  each  set  of  tran¬ 
quihty  assumptions  determines  which  scenarios  would  need  to  discard  that  set  of  assumptions. 

While  other  work  on  dynamic  lattices  (see  [13])  has  laid  down  the  formal  properties  that 
dynamic  lattices  must  satisfy,  a  system  implementing  dynamic  lattice  must  be  able  to  represent 
them.  Section  2.5.2  makes  two  specific  proposals  for  representing  and  managing  dynamic 
lattices.  The  first  solution,  which  employs  the  use  of  additional,  artificial  categories,  could  be 
useful  for  small  lattices  in  which  the  location  of  new  lattice  points  can  be  anticipated.  The 
second  solution,  which  iises  the  local  structure  of  the  security  lattice,  is  more  practical  for 
larger  lattices  and  for  situations  in  which  the  inclusion  of  lattices  is  unanticipated. 

Section  2.5.3  proposes  a  High-Water  Mark  Confidentiahty  Audit  Pohcy.  When  attempting  to 
recover  fix)m  ^e  relaxed  pohcy,  the  mechanisms  described  could  be  used  either  as  an  auditing 
tool  to  determine  if  subjects  and  objects  had  really  be  contaminated  with  high  level  information, 
or  it  could  be  used  for  the  sake  of  mandatory  access  controls  preventing  the  possibihty  of  further 
contamination  finm  occurring. 

Section  2.6  discusses  the  ramification  of  the  loss  of  tranquihty  on  specific  tasks  associated  with 
formal  assurance.  Although,  there  is  some  theoretical  work  on  the  subject  ([10]  anH  [9]),  there 
are  stUl  some  large  steps  to  take  to  fully  comprehend  the  nature  of  the  impact  that  an  adaptive 
security  pohcy  has  on  the  assurance  evidence  for  an  apphcation  or  system. 
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Section  ^ 

Audit 


3.1  Introduction 

Prior  work  on  adaptive  security  (see  [22])  discussed  the  use  of  auditing  to  assist  in  recoverj' 
from  a  period  of  relaxed  security.  To  facilitate  this  recovery,  tracing  of  information  flows  must 
be  performed.  Once  this  goal  is  accomplished  it  is  possible  to  know  what  objects  in  the  system 
have  been  contaminated  with  higher  security  level  data. 

Investigation  of  audit  logs  revealed  several  deflciencies  in  the  DTOS  auditing  information 
that  prevented  us  from  using  audit  logs  for  tracing  information  flow.  The  major  problem  was 
the  inability  to  relate  the  audited  fine  grained  permission  check  of  the  microkernel,  to  high 
level  activities  of  the  system.  For  example,  it  is  impossible  to  discern  that  a  file  was  being 
opened  via  audited  microkernel  permission  checks.  The  other  problem  was  that  not  enough 
information  was  presented  in  the  audit  data  to  be  able  to  relate  a  set  of  audited  permission 
checks  to  a  particular  chain  of  execution.  ®  We  addressed  these  deficiencies  by  modifying  the 
DTOS  prototype  to  provide  additional  data  on  each  audit  event,  and  by  auditing  service  request 
messages  and  their  contents. 

As  stated,  DTOS  audit  logs  do  not  provide  the  information  needed  to  be  able  to  relate  one 
audited  permission  check  to  another  audited  permission  check  in  a  single  chain  of  execution. 
The  approach  taken  to  rectify  this  situation  under  the  ASP2  program  is  to  maintain  a  tracing 
identifier  that  is  created  when  user  domains®  send  a  message.  This  tracing  identifier  (referred 
to  as  TID,  hereafter)  is  included  in  the  audited  information  for  each  audited  permission  check. 
If  the  receiver  of  the  message  is  not  another  user  domain,  the  TID  for  any  messages  the 
receiving  thread  sends,  will  be  the  TID  firom  the  last  message  received  by  that  thread.  The  TID 
is  used  to  group  a  set  of  audited  permission  checks  to  one  chain  of  execution. 

The  other  shortcoming  is  that  the  permission  checks  are  too  low  level  to  be  able  to  relate  to 
functional  operations.  The  majority  of  the  interesting  events  take  place  in  system  servers 
running  in  user  space.  To  address  this  shortcoming  under  ASP2,  the  kernel  was  modified  to 
snoop  all  messages  for  a  configurable  set  of  service  requests.  When  such  a  service  request  is 
found,  an  audit  event  is  generated  with  a  user  defined  set  of  the  service  request  parameters 
included  in  the  audit  data. 


3.2  Logical  Groupings  of  audited  permission  checks 

To  facilitate  grouping  of  microkernel  audit  data  related  to  a  particular  system  activity,  a  tracing 
identifier  (TID)  was  added  to  the  microkernel  thread  structure.  A  TID  value  is  set  in  one  of 
two  ways  depending  on  the  domain  of  the  task.  If  the  domain  is  considered  a  user  domain,  the 
TID  is  set  to  a  unique  value  when  the  thread  sends  a  message.  Otherwise,  the  TID  is  set  upon 
receipt  of  a  message.  In  this  latter  case,  the  receiver’s  TID  is  set  to  the  TID  of  the  sender’s 
thread. 

rKain  of  execution  »  all  the  procesemg  that  takes  place  in  order  to  eatisfy  a  single  eystem  service  request, 
including  processing  that  takes  place  in  several  different  servers. 

®A  user  domains  are  application  layer  domains.  System  domains  are  for  servers  and  the  microkernel. 
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Figure  3-8:  Traciug  Identifier  Flow 


In  Figure  3-8,  Thread  1  sends  a  message  (Message  lA)  to  Thread  2.  Assuming  Domain  A  is 
defined  as  user  domain,  a  new  TID  (TID  LA)  is  created  nnr)  assigned  to  the  thread  structure 
responsible  for  sending  the  message.  TID  lA  is  also  carried  along  in  the  message  to  Thread  2, 
The  thread  in  Thread  2  receiving  Message  lA  has  its  TID  value  set  to  TID  lA.  Next  Thread  2 
sends  a  message  (Message  2B)  to  Thread  3.  If  Domain  B  is  not  defined  to  be  user  domain,  then 
the  TID  assigned  to  the  message  wdll  be  the  TID  of  the  thread  sending  the  message.  In  this 
case  that  TID  would  be  TID  lA  ie,  TID  2B  would  be  the  same  as  TID  lA.  The  TID  value  for  the 
currently  executing  thread  is  then  appended  to  the  audit  data  sent  to  the  Audit  Daemon.  Thus 
the  audited  permission  checks  relating  to  a  specific  user  domain  service  request  will  all  bear 
the  same  TID  even  as  the  resolution  of  that  service  request  migrates  through  several  different 
tasks^servers. 

The  specification  of  which  domains  are  user  domains  is  performed  via  a  new  kernel  interface  on 
the  host  port.  This  interface,  hostMuditjcontrol,  allows  applications  to  set  anii  reset  a  domain’s 
user  status.  By  default,  domains  are  considered  not  to  be  user  domains.  The  security  of  this 
interface  is  controlled  via  the  usual  DTOS  means.  Thus  only  specific  domains  (auditing  domain 
for  example)  should  be  permitted  access  to  this  interface. 

While  this  method  for  grouping  permissions  is  sufficient  for  the  majority  of  cases,  servers  that 
circumvent  the  MACH  IPC  system  for  passing  processing  control  to  another  thread,  must  use 
a  manual  means  for  managing  TID  values.  In  order  to  fecilitate  migration  of  TID  values  for  a 
chain  of  execution  that  include  non  IPC  messsiging  (ie,  via  shared  memory)  a  new  service  was 
added  to  the  thread  port.  The  service  audit  thread  Jag  is  used  by  the  server  to  obtain  the  TID 
value  fiem  thread  structure  for  the  current  chain  of  execution.  The  server  must  then  inform 
the  new  thread  in  the  chain,  such  that  the  new  chain  may  also  invoke  the  audit  Jhread Jag 
request  to  set  its  TID  value.  The  audit  Jhread  Jag  request  should  only  be  permitted  for  the 
domains  in  which  the  multithreaded  servers  reside. 

No  attempt  was  made  to  modify  the  existing  multithreaded  DTOS  servers  (Lites  for  example) 
to  follow  the  rules  hsted  above.  Such  an  effort  was  beyond  the  scope  of  this  research  effort. 
Attempts  to  modify  multithreaded  servers  might  prove  to  be  difficult  depending  on  how  clearlv 
thread  hand  offs  are  marked  in  the  source  code,  and  how  centralized  are  the  implementations 
of  the  thread  hand  off  mechanism. 
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3.3  Auditing  of  system  servers  via  microkernel  snooping 

In  a  server/microkemel  architecture  such  as  DTOS,  the  majority  of  the  security  critical  events 
are  performed  by  system  servers  rather  than  the  microkernel.  An  example  of  ^s  is  the  Unix 
operation  of  opening  a  file.  In  the  DTOS  prototype,  this  operation  is  handed  by  sending  a 
file  open  service  request  to  tiie  Lites  Server.  One  approach  for  providi^  aumt  ^oi^tion  on 
similar  higher  level  activities,  is  to  modify-  each  server  to  interact  mth  the  Audit  Daemon  for 
each  service  provided.  Another  approach  is  to  centralize  the  auditing  of  all  semce  requests 
in  the  microkernel.  The  former  approach  is  the  ideal  auditing  mech^sm  m  that  the  se^er 
can  supply  the  audit  daemon  with  whatever  information  the  server  deems  appropriate.  The 
drawback  of  the  former  approach  is  that  all  service  request  routines  in  evety  server  ^ed  to 
have  auditing  code  inserted.  The  latter  approach  provides  a  flexible  system  that  lends  itself  to 
easy  integration  of  new  servers.  The  drawback  of  the  latter  approach  is  the  system  processing 
overhead  of  snooping  each  message. 

In  order  to  facilitate  auditing  of  services  provided  by  system  servers  without  modifying  the 
servers,  the  DTOS  microkernel  was  modified  to  snoop  messages  sent  to  servers  for  service  re¬ 
quests.  The  implementation  allows  an  external  agent  to  inform  the  rmcrokemel  that  messages 
sent  from  a  task  with  a  specified  subject  SID  with  a  specific  message  identifier  ,  sent  to  a  port 
with  a  specified  SID  ,  will  trigger  an  audit  event.  This  audit  event  will  have  a  specified  subset 
of  the  parameters  decoded  and  sent  as  part  of  the  text  of  the  audit  message.  The  subject  SID. 
message  identifier,  and  port  label  may  all  be  wildcarded. 


Figure  3-9:  Snooping  of  Service  Requests 

The  interface  hostjouditjxntrol  is  used  to  add  and  remove  entries  from  the  list  of  messages 
that  are  snooped.  The  performance  impact  of  the  message  snooping  increases  with  each  entry- 
in  the  list.  Thus  if  the  auditing  policy  requires  a  large  list  of  services  to  be  audited,  then  either 
a  more  efficient  algorithm  for  pattern  matching  of  the  message  would  need  to  be  developed,  or 
the  auditing  should  be  moved  into  the  service  routines  within  each  server. 


3.4  Implementing  adaptive  security  with  the  assistance  of  auditing 

By  itself;  the  DTOS  Security  Server  is  limited  to  permission  computations,  accessible  system 
state,  and  human  interaction  in  order  to  trigger  policy  adaptations.  However,  with  some  minor 

^The  Mach  IPC  mechaniEiD  includeB  an  integer  value  called  the  meaeage  ID.  Itie  value  ia  uaed  by  the  Mach  Interface 
Generator  (MIG)  to  differentiate  aervice  routinea  offered  on  a  amgle  port 


modifications  to  the  Security  Server  and  the  Audit  Daemon,  the  range  of  triggers  for  policy 
adaptations  has  been  considerably  expanded.  The  modifications  allow  the  Security  Server  to 
configure  the  Audit  Daemon  via  a  port  advertised  on  the  name  server.  The  Security  Server  can 
also  supply  a  send  right  to  a  pnart  on  which  it  will  be  notified  when  the  configured  audited  event 
takes  place.  For  example,  given  a  Chinese  Wall  (see  [20])  type  of  security  policy,  where  a  user 
is  permitted  access  to  either  of  two  files,  but  once  access  to  one  of  the  files  is  performed,  access 
to  the  other  of  the  two  is  restricted.  The  Security  Server  could  config^ure  the  audit  daemon  to 
audit  accesses  to  both  files  and  to  notify  the  Security  Server  when  such  an  access  takes  place. 
The  Security  Server,  upon  receiving  such  a  notification  (or  trigger),  would  adapt  the  security 
policy  such  that  access  to  the  other  file  is  restricted. 

At  this  time,  limited  controls  on  the  use  of  this  interface  have  been  implemented,  but  there  is 
some  security  risk  that  the  audit  configuration  port  could  be  used  to  create  an  auciit  configura¬ 
tion  that  cannot  be  ph3csically  supported  (for  example,  auditing  all  permission  checks  generates 
enough  auciit  messages  that  it  overflows  the  audit  port).  Or  the  interface  could  be  used  to  cre¬ 
ate  an  audit  configuration  that  supersedes  the  intended  auciit  functionality.  The  implemented 
controls  involve  the  Auciit  Daemon  returning  a  key  back  fium  every  audit  configuration  change. 
This  key  must  be  supplied  in  order  to  undo  the  configuration  change. 

The  implementation  of  the  auciit  configuration  interface  is  limited  to  rfianging  the  auditing  of 
service  recjuest  messages.  There  is  no  reason  for  the  Security  Server  to  have  the  Audit  Daemon 
monitor  permission  checks  on  behalf  of  the  Secmrity  Server  when  the  Security  Server  ran  set 
the  cacheable  flag  in  such  a  way  as  to  monitor  permission  checks  itself. 


3.5  Using  Auditing  to  recover  from  periods  of  relaxed  policy 

With  the  enhancements  to  the  DTOS  auditing  mechanism  described  above,  the  capability  to 
generate  an  auciit  trail  with  enough  contextual  information  to  discern  information  flows  has 
been  added  to  the  DTOS  prototype.  However,  in  order  to  make  use  of  this  information  the 
auditing  mechanisms  must  be  configured  to  look  for  the  significant  information  flows.  To 
address  this  recjuirement,  a  rudimentary  scheme  to  automating  the  auditing  configuration 
was  implemented.  This  scheme  involved  comparing  two  security  policy  files.  The  automation 
tool  generated  an  auciit  configuration  for  the  difference  between  the  two  policies.  A  more 
involved  scheme  would  involve  an  automation  tool  that  is  aware  of  data  flow  significance  of 
each  permission  pair  and  would  generate  an  auciit  configuration  that  only  audits  significant 
differences. 

Another  means  of  monitoring  leakage  of  information  from  a  high  security  level  to  a  low  security 
container  would  be  to  modify  the  Auciit  Daemon  to  adapt  its  auciit  policy  on  the  fly,  based  on 
prior  audited  events.  While  this  modification  was  not  performed  as  part  of  the  ASP  2  program, 
it  is  easy  to  see  how  it  could  be  utilized.  With  an  Audit  Daemon  modified  in  such  a  manner,  the 
Auciit  Daemon  would  recognize  when  high  security  data  was  placed  in  a  low  security  container. 
At  this  point  the  Audit  Daemon  would  reconfigure  the  audit  policy  to  also  monitor  information 
flows  fiem  this  low  security  container,  as  it  is  now  contaminated  with  high  security  data. 

3.6  Conclusions 

It  is  obvious  that  in  order  to  evaluate  and  recover  fiem  a  period  of  relaxed  security  policy,  there 
is  a  need  to  track  information  flows  that  take  place  diuing  this  period.  Auditing  can  be  a  useful 
tool  for  use  by  the  Security  Server  and  by  security  administrators  to  monitor  system  activity 
and  information  flows.  On  the  DTOS  prototype  the  Security  Server  implements  the  policy  for 
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the  DTOS  microkernel  and  to  some  extent  the  Lites  Unix  Server.  Any  service  pro\dded  by  a 
system  server  that  is  not  controlled  by  the  Security  Server  cannot  be  momtored  for  u^ormataon 
flows  by  the  Security  Server.  In  this  case,  if  the  service  can  be  momh^d  via  auchtmg,  the 
Security  Server  could  use  the  Audit  Daemon  to  monitor  the  information  flows  even  though  the 
Security  Server  cannot  directly  control  the  interface.  In  addition,  tracing  identifier  penmt 
the  differentiation  of  information  flows  between  applications  and  system  severs,  \\ith  the 
modifications  to  the  DTOS  prototype  to  permit  microkernel  snooping  of  service  requests^d 
the  addition  of  tracing  identifiers,  it  is  feasible  to  utilize  audit  data  m  recovery  ^m 

a  period  of  relaxed  security  policy.  The  tools  and  modifications  to  the  DTOS  prototype  wm  be 
made  avmlable  in  the  next  release  of  the  DTOS  prototype.  Future  work  m  this  area  could  be 
oriented  toward  automating  recovery  from  the  period  of  relaxed  policy  pven  the  information 
flows  presented  from  the  audit  log.  Other  avenues  of  investigation  could  include  dynamic  audit 
policies  and  further  automation  of  audit  policy  generation. 
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Section  ^ 

Security  Database  Tools 


4.1  Introduction 

This  section  describes  the  design  and  implementation  of  tools  for  constructing  security 
databases. 

For  any  automated  information  system  (AIS)  which  is  expected  to  enforce  a  security  policy,  the 
security  pohcy  must  be  encoded  in  a  database  that  the  AIS  can  read  and  interpret.  For  the  DTOS 
prototype  it  is  the  Security  Server  that  defines  the  policy,  and  makes  security  computations  on 
behalf  of  Ibe  microkernel  and  other  servers.  The  Security  Server  defines  the  security  policy 
from  the  time  that  it  is  initialized  by  reading  its  security  database.  With  an  adaptive  securitv' 
pohcy,  there  are  two  or  more  pohcies  under  which  the  AIS  may  run.  wnH  therefore  it  is  necessary 
to  construct  two  or  more  databases  lo  define  the  security  pohcy  after  each  transition  in  addition 
to  the  initial  definition.  Although  the  similarities  between  the  two  pohcies  may  be  greater  than 
the  differences,  it  can  be  a  difficult  task  to  manage  the  information  that  must  change  from  one 
pohcy  to  the  next.  Maintaining  a  large  database  by  band,  using  only  a  text  editor  for  example, 
is  prone  to  error.  The  alternatives  to  maintaining  a  database  by  band  include  generating  the 
security  databases  by  compiling  a  text  based  specification  lani^age  or  by  encapsulating  the 
specification  in  a  tool.  The  approach  taken  on  this  program  is  to  encapsulate  the  specifications 
in  a  security  database  tool  with  a  graphical  user  interface.  This  approach  was  chosen  over 
creating  a  formalism  for  high  level  security  pohcies  as  a  result  of  usabihty  anrl  implementation 
concerns. 

The  design  of  a  database  tool  must  meet  the  following  specifications: 

■  It  must  allow  the  user  to  specify  the  pohcy  in  real-world  terms;  i.e.  it  must  help  the  user 
map  her  organization’s  security  pohcy  to  the  security  pohcy  that  will  be  enforced  by  the 


■  It  must  not  prevent  the  user  from  eSectively  controlling  the  permission  set  at  the  lowest 
levels. 

■  It  must  provide  access  to  the  Adaptive  Pohcy  Mechanisms  supported  by  the  Security 

Server.  ^ 


The  following  subsections  of  this  report  will  discuss  the  set  of  existing  database  tools  for 
the  DTOS  prototype  and  the  design  and  implementation  of  the  GUI  tools  for  specifying  the 
database. 

Before  continuing  with  the  following  descriptions,  it  will  be  helpful  to  define  clearly  two  terms 
that  shall  be  used  throughout  the  remainder  of  this  section:  pohcy  files  anrl  database  files.  The 
first  term  refers  to  files  created  by  the  security  administrator  (tool  user)  to  define  the  security 
pohcy.  The  latter  refers  to  the  processed'’  pohcy  files  that  are  the  actual  input  files  for  the  AIS 
(in  the  case  of  the  DTOS  prototype,  the  Security  Server’s  security  database  files). 

processed  -  in  that  they  are  automatically  constructed  from  the  policy  files  by  the  database  tools 
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4.2  Existing  database  tools 

The  DTOS  prototype  is  supplied  with  rudimentary  database  tools.  These  tools  consist  of  a 
Makefile  that  processes  the  pohcy  files  through  the  M4  macro  processor  and  some  ^rl  scripts. 
The  M4  macro  processing  step  provides  a  limited  capability  to  logically  group  permission  pairs 
into  functional  sets.  The  Perl  scripts  perform  the  task  of  converting  symbohc  permission  names 
into  bit  positions  in  an  access  vector. 

The  are  two  problems  with  the  existing  database  tools.  First,  the  macros  used  to  logically 
group  the  pairs  represent  a  very  high  level  of  abstraction  that  prevents  simple  modifications  to 
specific  domains.  Typically,  one  must  duphcate  the  entire  macro  for  the  specific  domains  to  be 
modified  niiH  change  one  of  the  macros  to  contain  the  sp^ecific  modification,  while  leaving  the 
unmodified  macro  for  use  by  all  other  domains.  The  second  problem  is  the  non-obvious  syntax 
of  both  sets  of  text  files  which  makes  human  interpretation  of  the  database  files  difficult.  To 
address  the  problems  presented  above,  a  GUI  database  tool  was  created. 

4.3  Design  and  Implementation  of  database  tools 

Two  approaches  were  considered  for  developing  database  tools  to  support  the  Adaptive  Security 
Pohcies  Experience  program.  The  first  approach  was  to  develop  a  formalism  for  specifying 
higher  level  security  policies,  then  create  database  tools  to  take  the  formal  pohcy  specification, 
flriH  convert  it  into  database  files  for  the  Security  Server.  The  work  in  progress  at  ORA  and 
Secure  Computing’s  TESLA  pohcy  specification  language  are  examples  of  this  approach  that 
were  investigated  for  apphcabOity  to  this  program.  The  work  at  had  not  progressed  far 
enough  to  be  available  for  use,  and  the  TESLA  pohcy  specification  language  was  not  deemed  to 
be  appropriate  for  adaptive  pohcies. 

The  second  approach  was  to  utilize  a  GUI  database  tool  that  generated  security  database 
files.  Such  a  tool  obviates  the  need  for  the  pohcy  writer  to  learn  a  specification  language. 
This  approach  is  characterized  by  the  Adage  tool  set  from  the  Open  Group  Research  Institute. 
This  latter  approach  utilizing  the  Adage  toolset  was  the  preferred  approach  to  the  creation 
of  database  tools  due  to  preexisting  technology  and  the  ease  of  creating  and  editing  security 
pohcies  with  a  GUI  based  tool.  However,  the  Adage  tool  set  was  in  the  process  ofbeing  rewritten 
during  the  timeframe  of  this  program.  This  resulted  in  the  decision  to  build  a  GUI  database 
tool  set  locally.  In  order  to  provide  a  visual  interface,  a  database  tool  was  created  to  run  on  a 
Windows  95  /  Windows  NT  system.  This  choice  was  made  due  to  the  wealth  of  development 
tools  available  for  the  Windows  platform. 

The  database  tools  developed  for  the  DTOS  prototype  under  this  program  have  been  designed 
to  meet  the  following  requirements: 

1.  Permit  grouping  of  permissions  into  hierarchical  sets. 

2.  Provide  an  easy  upgrade  path  from  the  existing  DTOS  pohcy  files  by  supporting  the 
existing  file  format  (read  only). 

3.  Support  a  specific  adaptation  mechanism. 

4.  To  minimize  modifications  to  the  Security  Server,  the  database  tools  must  use  a  format 
for  the  database  files  compatible  with  the  existing  DTOS  Security  Server.  (With  the 
exception  of  adaptation  information) 

To  meet  the  first  requirement,  and  to  ease  the  implementation  of  the  second,  the  GUT  tool 
continues  to  support  the  concept  of  macros,  which  are  the  basic  building  blocks  of  the  security 
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policy.  Each  modiilar  entity  in  the  security  policy  should  be  relegated  to  its  own  macro,  thus 
providing  the  capabihty  to  build  up  a  security  policy  in  a  modular  fashion.  The  shortcoming 
of  modular  construction  of  a  security  policy  is  the  need  to  provide  for  exceptions  to  the  default 
behavior  of  a  module.  The  GUI  tool  was  designed  to  handle  these  exemptions  by  proriding  the 
capability  to  edit  a  macro  and  to  apply  the  edited  macro  either  to  all  invocations  of  the  macro, 
or  to  just  the  current  invocation  of  the  macro.  The  implementation  of  this  feature  in  the  GUI 
tool  was  not  completed  due  to  time  constraints. 

The  implementation  of  the  GUI  tool  supports  reading  the  old  format  of  policy  files  but  has  its 
own  native  format  for  saving  and  restoring  policy  files.  The  decision  to  use  a  native  file  format 
for  saving  policy  files  was  based  on  the  number  of  unique  files  and  formats  that  were  used  to 
define  the  DTOS  format  of  policy  files.  The  DTOS  format  of  policy  files  used  eleven  files  with 
six  different  fonnats.  This  was  consolidated  into  one  file  in  the  native  format  file. 

Two  types  of  policy  adaptation  mechanisms  where  considered  in  developing  the  database  tools, 
time-of-day-based  adaptations  and  event-based  adaptations.  A  tdme-of-day  based  adaptation 
is  an  adaptation  that  takes  place  at  a  specific  time  of  day,  every  day.  For  example,  a  bank’s  AIS 
may  start  to  restrict  account  transactions  at  5pm.  Those  restrictions  may  be  removed  at  Sam 
the  following  day.  The  second  type  of  policy  adaptation,  event  based  adaptations,  provides  for 
most  other  types  of  policy  adaptations.  An  event  can  be  considered  to  be  any  form  of  automated 
trigger  to  a  policy  change.  The  trigger  could  be  an  audit  event,  a  particular  permission  check, 
a  signal  from  an  intrusion  detection  daemon,  or  any  other  system  or  security  events. 

To  support  these  two  types  of  adaptation  means,  two  subframes  (or  windows)  of  the  GUI  inter¬ 
face  have  been  defined.  The  first  subframe  is  used  to  generate  time-of-day  based  adaptations. 
The  second  is  used  to  define  event  based  adaptations.  These  subframes  require  the  pohcy 
writer  to  create  a  macro  that  defines  the  policy  action  which  will  take  place  when  adaptation 
criteria  is  met.  When  the  GUI  tool  generates  the  database  files,  the  adaptation  information 
will  be  included  in  a  new  section  of  the  files.  The  DTOS  Security  Server  was  modified  to  use 
the  adaptation  information  to  generate  time  of  day  based  adaptations.  However,  due  to  time 
constraints,  event-based  adaptations  were  not  implemented  as  part  of  this  program. 

The  screenshots  in  Figure  4-10  through  Figure  4-15  show  various  frames  of  the  security 
database  tools. 

•  Figure  4-10  shows  the  starting  display  of  the  database  tool  after  the  database  files  have 
been  loaded.  Note  the  list  of  macro  invocations  in  the  upper  right  half  of  the  screen  wnH 
the  base  policy  SID  pairs  in  the  lower  half  of  the  screen.  The  controls  on  the  upper  left  of 
the  fiume  control  the  Type  Enforcement  primitives  and  the  MLS  relations.  The  controls 
in  the  middle  of  the  left  side  are  for  controlling  policy  adaptations. 

■  The  interface  used  to  modify  the  permissions  associated  with  a  given  database  pair  is 
illustrated  in  Figure  4-11.  The  permission  names  are  parsed  directly  from  the  *.h  files 
that  define  the  access  vectors. 

■  In  Figure  4-12  the  interface  used  to  create  and  edit  macros  is  shown.  The  parameters  to 
the  macro  (am  be  referenced  by  \ising  $1,  $2,  $3,  tmd  $4  for  parameters  one  through  four 
respectively. 

■  Figure  4-13  shows  the  specialized  form  used  to  create  time-of-day  based  policy  adapta¬ 
tions. 

■  Figure  4-14  demonstrates  the  interface  used  to  edit  MLS  flows  associated  with  specific 
permission.  In  the  DTOS  prototype,  each  permission  may  be  associated  with  an  MLS  in- 
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formation  flow.  This  interface  allows  the  database  developer  to  redefine  tiiese  information 
flows,  or  to  spedf>’  the  information  flow  for  a  new  permission. 

■  Figure  4-15  illustrates  the  interface  used  to  invoke  macros. 


4.4  Conclusions 

Security  policy  database  files  for  any  moderately  complex  AIS  will  require  some  form  of  man¬ 
agement  tools  as  the  complexity  of  the  database  files  precludes  direct  human  management. 
The  policy  management  tools  designed  under  this  program  support  a  hierarchical  system  of 
building  up  a  security  policy  without  preventing  variations  from  the  default  hierarchy  by  spe¬ 
cific  domains.  And  while  the  implementation  of  these  tools  is  tailored  for  the  DTOS  prototype, 
the  design  is  applicable  to  any  Type  Enforced!  1]  security  system.  These  database  tools  will  be 
made  available  with  the  neirt;  release  of  the  DTOS  prototype. 

The  next  step  in  the  utilization  of  the  GUI  database  tools  would  be  to  regenerate  the  DTOS 
pohcy  files  from  scratch.  In  the  process  of  regenerating  the  policy  files,  special  attention  woiald 
be  given  to  modularizing  the  policy  into  a  hierarchical  set  of  macros.  This  new  hierarchical  set 
of  macros  would  permit  the  GUI  tool  to  be  more  effective  in  creating  policies  that  incorporate 
least  privilege.  Other  avenues  of  investigation  coxild  involve  unifying  the  audit  pohcy  and  the 
security  policy  into  one  pohcy  tool  and  increasing  the  range  of  adaptations  supported  by  the 
pohcy  tool  and  Security  Server  to  include  event-based  adaptations. 
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include{dalabase_macros.m4) 

trans_access_priv(Unix,userT ) 

trans_dccess_standar  d(U  nix,U  nixT ) 

trans_access_standard(Unix,negotiationT) 

trans_access_standard(Unix,securityT) 

iinix_proc(Unix,unix,uset,user) 

ss_services(security,sec,user,user) 

sec_unix_proc(Unix,unix,security,sec) 

sec_unix_exec(user.user,security,sec) 

unix_proc(U  nix,unix,negotiaticin,negotiafon] 

ss_services(security,sec,negotiation,negotiatiori) 

sec_unix_exec{negotiatiori,negotialion,secijrity,sec) 

tfans_access_$landard(user,userT) 

trans_access_standard(user,U  nixT ) 

trans_access_standard(user, negotiation!)  k 

trans_access_standard(user,securityT ) 

unix_proc(Llnix.unix,daemon,daemon] 

ss_$ervice$(security,sec,daemon,daemon] 


kernel->kernJask_porl 

kemel->kern_thread_port 

kernel->kern_mem_obLport 

kernel->outcall_repiy_port 

kernel->audit_feply_port 

kernel->bool_port 

kern_kern_derived_$id->boot_port 

kern_kern_derived_sid->start_port 

kern_kern_derived_sid->unix_port 

kerne!->unix_mem_obLport 

I  . A. ...I  *...A 4  . •.  .  . 


Figure  4-10:  The  GUI  Database  Tool 


Figure  4-11:  Permission  Modification  Frame 
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$1  ■>  J4_task_por> 

kemel->  $2_mem_obLport 

boo{strap->  $2_mem_obLport 

$1  •>$4_mem_obLport 

kemal->  $4_mem_obLport 

$1  ■>$4_mem_obL.cfr!_port 

$1  •>$4_thread_port 

$1  •>$4_port 

$3->i2_task_port 

$3->$2_lhread_pof( 

$3->$2_poft 

$3->  i2_mem_obLport 

$3->sec_port 

$3->boot_port 

$3->  boot_niem_(^i_poft 

$3->$4_lask_porl 

$3->$4_lask$elf_port 

$3->$4_khread_poft 

$3->  $4_thf  eadself_port 

$3  >i4  port 


Figure  4-12:  Macro  Editing  Frame 
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Figure  4-13:  Adaptation  Generating  Frame 
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Figure  4-14:  Controls  for  Specifying  MLS  flows 


Figure  4-15:  Macro  Invocation  Frame 
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Section  ^ 

Trade-Off  Study 


5.1  Introduction  to  the  Trade-Off  Study 

The  Trade-Off  Study^  compares  four  methods  for  implementing  adaptive  security  poUcies. 
Two  of  these  methods  were  identified  in  [22]  but  two  of  these  have  been  conceived  «nd  partially 
implemented  for  the  sake  of  the  current  study. 

Several  criteria  have  been  identified  for  the  sake  of  comparing  these  implementations.  These 
criteria  are  defined  and  explained  in  the  following  section;  however,  in  order  to  adequately 
compare  implementations  of  adaptive  securitj'  policies,  it  is  important  to  keep  in  mind  the 
security  and  functional  needs  ofoi^ganizations  that  would  deploy  systems  with  adaptive  security 
policies.  The  following  several  paragraphs  outline  several  examples  and  scenarios  for  which 
adaptive  security  pohcies  would  be  implemented  and  deployed.  Some  of  the  following  examples 
are  also  covered  in  Section  2.3.4. 

The  first  example  of  adaptive  security  consists  of  organizations  that  need  to  change  their  policies 
at  regular  intervals.  For  example,  a  bank  may  have  one  security  policy  enforced  during  business 
hours  and  another  policy  enforced  after  hours.  The  business-hours  policy  would  grant  broad 
sets  of  permissions  to  various  sets  of  employees  in  order  complete  normal  banking  transactions; 
however,  a  more  restrictive  policy  would  be  in  effect  after  hours  to  prevent  system  users  from 
altering  banking  data  in  unintended  ways. 

Some  organizations  may  need  to  release  sensitive  documents  at  si)ecific  times  (see  Sec¬ 
tion  2.3.4. 1).  For  commercial  organizations  it  may  be  a  press  release  or  new  product  information 
that  must  not  be  available  from  the  Webserver  until  a  specified  time.  Military  organizations 
may  have  similar  needs  to  make  information  available  to  allies  on  a  timed-release  basis.  Con¬ 
versely,  a  commercial  partner  or  military  ally  may  be  an  adversary  tomorrow  in  which  case 
they  may  not  be  allowed  to  receive  various  forms  of  information. 

Other  organizations  may  need  to  adapt  their  security  policies  based  on  the  facVc  performed 
by  the  users.  For  example,  in  the  banking  example  dted  above,  some  tasks  may  be  critical 
to  perform  despite  the  more  restrictive  policy  enforced  after  5:00  PM.  High-priority  or  urgent 
tasks  may  need  to  be  granted  special  permissions  to  complete  on-going  operations  despite  the 
general  change  of  policy.  Other  task -based  policies  may  make  use  of  an  assured  pipeline,  like 
that  proposed  by  Boebert  and  Kain  [2].  Assured  pipelines  address  situations  in  which  a  series 
of  tasks  must  be  performed  in  a  particular  order  and  the  control  flow  must  be  restricted.  An 
adaptive  policy  might  change  the  set  of  permissions  associated  with  a  single  process  so  that, 
as  the  prucess  completes  one  operation,  the  permission  set  then  allows  the  process  to  complete 
the  next  operation  but  prevents  it  from  revisiting  objects  that  it  needed  to  access  for  earlier 
operations.  A  related  security  policy  would  be  the  Chinese  Wall  introduced  by  Brewer  and  Nash 
[3],  which  is  intended  to  prevent  conflicts  of  interest  in  commercial  settings.  Briefly,  under  a 
Chinese  Wall  security  policy  a  subject  may  initially  be  allowed  permission  to  an  entire  class  of 
objects,  but  as  soon  as  the  subject  accesses  one  element  of  the  class,  permissions  to  access  any 
other  object  of  that  class  are  denied. 


-The  results  of  the  Trade-Off  Study  were  accepted  for  publication  by  the  199S  USENK  UNIX  Security  Symposium 
in  [4]. 
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Another  class  of  examples  of  adaptive  secuiitj’  policies  are  role-based  policies  (see  Sec¬ 
tion  2. 3.4. 2).  A  role  is  distinguished  from  a  task  in  that  an  individual  has  an  on-going  need 
to  complete  a  set  of  tasks.  In  commercial  settings,  roles  may  be  used  to  enforce  separation 
of  duties  (such  as  purchasing  from  disbursement  of  funds).  For  small  companies  it  may  be 
necessary  for  one  individual  to  perform  actions  in  more  than  one  role,  though  not  necessarily 
at  one  time,  to  provide  proper  controls  oversight.  Other  commercial  policies,  like  Chinese 
Wall  (see  [3]),  limit  the  access  of  a  user  to  certain  sets  of  files  to  prevent  conflicts  of  interest. 
In  military  operations  it  may  be  necessary  for  an  individual  to  perform  actions  in  more  than 
one  role  simiiltaneously.  In  ^e  Navy  for  example,  the  role  of  the  Watch  Officer  on  a  ship  may 
be  performed  by  the  Chief  Engineer.  It  may  be  necessary  for  the  Chief  Engineer  to  access 
engineering  information  as  the  Watch  Officer.  Similarly,  the  Command  Duty  Officer  may  need 
to  perform  aictions  reserved  for  the  Commanding  Officer  in  times  of  emergency.  The  invocation 
of  such  privileges  should  be  restricted  for  only  those  times  at  which  they  are  needed. 

A  final  class  of  examples  in  which  adaptive  security  jiohcies  is  necessary  applies  primarily 
to  military  or  intelligence  situations  which  apply  multilevel  security  (MLS)  rules.  Adaptive 
policies  may  allow  either  a  relaxation  or  selective  hardening  of  confidentiality  restrictions  (see 
Section  2.3. 4.3).  Under  MLS  rules  all  objects  are  labeled  according  to  the  sensitivity  of  the 
data  they  contain;  e.g.  Top  Secret,  Secret,  Confidential,  and  Unclassified.  Users  and  subjects 
are  allowed  access  to  observe  objects  only  if  their  clearance  level  is  equal  to  or  exceeds  the 
sensitivity  of  the  object.  During  an  emergency  it  may  be  necessary  to  collapse  levels  into  two 
levels:  Classified  for  Secret  and  Top  Secret  files,  and  Unclassified  for  the  remainder.  Thus. 
under  the  relaxed  rules  someone  formerly  cleared  for  Secret  could  access  files  formerly  labeled 
as  Top  Secret.  For  example,  military  officers  may  only  have  clearance  to  the  level  of  Secret, 
but  once  their  troops  are  under  fire,  they  may  need  to  access  Top  Secret  information  such  as 
the  location  or  capabilities  of  enemy  forces.  Conversely,  confidentiality  rules  and  other  security 
measures  could  ^  “hardened  up"  based  on  DEFCON  alert  status  or  following  detection  of  a 
possible  intrusion.  There  are  a  number  of  ways  to  “harden  up”  a  system.  Among  others,  one 
could  increase  internal  controls,  perform  full  audits  rather  than  selective  audits,  or  require 
additional  authentication  measures. 

Any  implementation  of  adaptive  seoirity  presents  its  own  set  of  advantages  and  disad\'antages. 
Section  5.2  describes  the  criteria  against  which  implementations  of  adaptive  security  may  be 
measured.  Section  5.3  describes  the  range  of  possible  implementations  for  adaptive  security’ 
given  the  basic  security  architecture  of  DTOS  (background  information  about  DTOS  is  given  in 
Appendix  A  and  [22]).  The  final  section,  Section  5.4,  describes  in  greater  detail  the  four  specific 
implementations  researched  at  Secure  Computing  Corporation  and  evaliaates  each  with  respect 
to  the  criteria  from  Section  5.2. 


5.2  Criteria  for  Evaluation 

This  section  describes  the  criteria  against  which  the  four  implementation  methods  identified 
above  are  evaliiated. 

The  goal  of  providing  an  adaptive  security  policy  for  a  computer  system  is  to  match  the  flexibility 
required  by  the  organization  that  fields  the  system.  There  are  two  types  of  flexibility  to  consider: 
policy  flexibility,  the  range  of  policies  that  a  system  can  support  before  and  after  a  transition 
between  poHdes,  and  function  flexibility,  the  ability  of  users  to  complete  tasks  despite  the 
transition  of  poHcies.  However,  greater  flexibility  may  come  at  the  expense  of  security  and 
assurabihty,  and  the  greater  complexity  required  for  some  types  of  transitions  may  have  an 
impact  on  the  reliability  of  the  system. 


43 


The  criteria  identified  here  are  not  independent  of  one  another,  in  fact  examining  various 
implementations  for  adaptive  security’  leads  to  a  series  of  trade-offs  with  respect  to  these 
criteria.  The  conclusions  that  are  drawn  from  the  analysis  of  the  four  implementations  reflect 
the  nature  of  the  dependence  of  the  criteria  upon  one  another. 


Policy  Flexibility  The  DTOS  Security  Server  can  enforce  a  wide  variety  of  security  policies  [24], 
Thus,  in  one  sense  the  DTOS  prototype  is  “flexible”  with  regard  to  the  number  of  security 
policies  that  can  be  enforced.  In  the  context  of  adaptive  security,  the  concept  of  policy  flexibility 
could  be  measimed  by  the  amoimt  of  change  one  is  allowed  to  make  and  whether  the  system 
can  enforce  an  aihitrary  new  policy.  Thus,  policy  flexibility  depends  on  the  number  ofj  or  lack 
of)  constraints  that  must  be  satisfied  by  the  successor  policy  for  a  given  predecessor  poHcy. 


Functional  Flexibility  Functional  flexibility  addresses  whether  the  policy  transition  is  graceful 
or  harsh  with  respect  to  the  applications  that  are  running  at  the  time  of  the  transition.  A  harsh 
transition  might  be  like  turning  off  the  power  and  re-booting  the  system,  whereas  a  graceful 
transition  may  appear  seemless  to  the  user  and  most  apphcations  on  the  system.  A  harsh 
policy  transition  may  prevent  users  from  performing  necessary,  possibly  tugent,  tasks,  rather 
than  allowing  them  to  complete  their  tasks  in  an  evolving  security  environment.  The  ideal  is 
to  allow  necessary  tasks  to  complete  while  terminating  tasks  which  are  not  only  disallowed 
under  the  new  policy,  but  which  represent  a  seciuity  risk  in  the  new  environment. 


Security  The  existence  of  a  mechanism  or  method  of  changing  policies  may  introduce  security 
vulnerabilities.  In  assessing  a  method  of  policy  adaptation,  this  paper  will  consider  the  security 
risks  that  are  inherent  in  that  method  of  policy  adaptation. 


Assurability  Each  type  of  policy  transition  wiD  be  assessed  for  the  relative  difficulty  of  pro¬ 
viding  formal  assiu^ce  evidence  in  support  of  the  policy  transition.  To  some  extent  this  was 
discussed  in  Section  2.6,  but  this  section  will  add  some  comments  depending  on  the  specific 
implementation. 


Reliability  Each  method  of  policy  transition  introduces  a  measure  of  complexity  into  the  system. 
Changing  policy  may  expose  the  system  to  certain  risks  which  decrease  the  stability  of  the  entire 
system. 


Performance  Performance  addresses  how  quickly  the  poHcy  transition  occurs.  The  ability  to 
change  policies  quickly  has  impact  on  the  needs  of  the  user  for  security,  functionality,  and 
reliability.  A  complex  hand-off  may  allow  greater  flexibihty  between  policies  enforced  before 
HTid  after  the  transition,  but  it  may  also  present  greater  security  risks.  A  less  complex  hand -off 
may  provide  performance  gains  at  the  expense  of  functional  grace  or  of  flexibility  of  specifying 
security  policies. 


5.3  Implementation  Space 

The  Distributed  Trusted  Operating  System  (DTOS)  Prototype  provides  a  security  architecture 
that  separates  the  enforcement  of  the  security  poHcy  from  its  definition.  Details  about  the 
DTOS  design  are  presented  in  Appendix  A  and  [22].  Since  this  type  of  security  architecture  is 
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not  unique  to  tlie  DTOS  Prototype,  results  from  this  study  will  apply  to  a  variety  of  systems 
with  similar  architectures  as  well. 

Elements  available  to  adapt  the  security  policy  include  the  following: 

■  the  number  or  complexity  of  the  databases  that  a  Security  Server  uses  to  initiahze  its 
internal  state, 

■  the  number  of  Security  Servers  available  to  the  microkernel  for  securi'fy  computations, 
and 

■  the  control  over  which  Security  Server  makes  security  computations  on  behalf  of  the 
microkernel. 

Although  the  number  of  possible  implementations  is  large,  this  study  only  describes  the  fol¬ 
lowing  representative  implementations: 

■  One  Security  Server  and  miiltiple  databases  —  adapting  the  policy  by  forcing  the  Securitj- 
Server  to  re-initialize  from  a  new  security  database. 

■  One  Security  Server  and  one  database  —  adapting  the  policy  by  expanding  the  internal 
state  of  the  Security  Server  and  increasing  tiie  complexity  of  the  security  database  to 
describe  more  than  one  set  of  security  policy  rules  and  by  providing  the  Security  Server 
with  a  mechanism  for  chflnging  its  mode  of  operation- 

■  Multiple  Security  Servers  with  a  single  active  server  providing  one  point  of  control  over 
security  computations  —  adapting  the  policy  by  providing  a  mechanism  to  hand  off  the 
responsibility  of  computing  access  decisions  from  one  server  to  another.  Thus,  one  and 
only  one  Security  Server  defines  the  policy  at  any  given  time. 

■  Multiple,  concurrent  Security  Servers  with  responsibility  for  security  computations  parti¬ 
tioned  by  tasks  —  adapting  the  policy  by  assigning  a  pointer  to  a  specific  Security  Server 
to  each  new  process.  In  this  method,  whenever  a  process  makes  a  request  to  the  microker¬ 
nel  for  service,  the  microkernel  submits  requests  for  access  computations  to  the  Securin' 
Server  which  is  associated  with  that  process  and  which  defines  the  security  pohcy  with 
respect  to  that  process. 

5.4  Comparison  of  Implementations 

This  section  of  the  study  will  describe  each  of  the  methods  for  changing  the  security  pohcy  in 
greater  detail  along  with  the  capabihties  and  limitations  presented  by  each. 

I 

5.4.1  Loading  A  New  Policy  Database 

One  possible  method  for  implementing  a  new  security  pohcy  is  to  change  the  way  that  the 
Security  Server  defines  it  by  creating  a  second  database  and  re-initializing  the  Security  Server. 
A  method  for  doing  this  existed  on  the  DTOS  prototype  already.  During  the  boot  process,  the 
microkernel  operates  on  a  hard-coded  cache  of  permissions  until  the  Security  Server  is  ready 
for  operation.  Once  the  Security  Server  has  initialized,  the  microkernel  places  the  command 
SSIJoacLsecurity  .policy  on  security  port  of  the  Security  Server.  This  command  causes  the 
Security  Server  to  read  the  security  database  to  construct  in  its  internal  memory  a  table  that 
maps  ^Is  and  OSIs  to  permissions.  The  Security  Server  then  teUs  the  microkernel  to  flush 


45 


its  cache  of  permissions,  and  from  that  point  onward  the  pohcy  defined  by  the  Security  Server 
is  the  pohcy  enforced  by  the  microkernel.  The  same  comniand  can  be  used  to  replace  one  table 
with  another.  Once  the  Security  Server  has  loaded  the  new  pohcy,  it  tells  the  microkernel  to 
flush  its  cache,  and  the  new  pohcy  is  enforced  by  the  microkernel. 

The  command  to  reload  pohcy  can  be  encapsulated  in  a  user-invoked  program  or  in  some 
automated  process  which  changes  the  ix)hcy  at  the  triggering  of  some  event.  Thus,  the  pohcy  can 
be  changed  at  regular  intervals  using  a  process  like  the  UNIX  utihty  cron,  or  by  a  background 
process  which  monitors  the  system  for  intrusion  events. 


Policy  Flexibility  This  method  rehes  heavily  on  the  tables  that  can  be  loaded  into  the  Security 
Server  from  the  security  database.  Since  the  tables  are  indexed  by  the  SSI  and  OSI,  the 
management  of  the  system  is  easiest  if  the  Security  Server  loads  a  new  pohcy  which  is  similar 
to  the  old  one.  A  radical  change  of  pohcy  requires  that  each  entity  in  the  system  have  a  security 
context  which  can  be  recognized  by  the  active  Security  Server  before  and  after  the  pohcy  change. 

For  initial  pohcies  based  on  Type  Enforcement  [2]  or  MLS  access  rules,  it  would  be  difficult  to 
make  radical  changes  in  the  pohcy.  Every  entity  that  has  a  type  or  domain  associated  with 
it  must  also  have  the  attributes  necessary  for  enforcing  the  different  p>ohcy.  Thus,  to  change 
from  a  pohcy  which  enforces  a  combination  of  MLS  and  Typve  Enforcement  rules  to  a  UNIX- like 
security  pohcy,  it  would  be  necessary  for  objects  and  processes  to  have  attributes  necessary  for 
both  sets  of  security  mechanisms.  For  objects  it  is  necessary  to  maintain  contexts  for  the  type 
and  sensitivity  level  of  the  object  as  weh  as  the  users  and  groups  which  may  have  access  to  the 
object.  For  subjects,  it  is  necessary  to  maintain  the  domain  a^  clearance  level  of  the  subject 
as  weh  as  the  user  of  the  subject.  It  is  also  necessary  to  maintain  a  database  hsting  the  group 
membership. 


Functional  Flexibility  Since  the  transition  between  pohcies  during  the  loading  of  a  new  pohcy 
is  nearly  atomic,  this  implementation  is  qmte  harsh  on  running  apphcations.  Any  apphcation 
which  ceases  to  have  permission  to  perform  any  task  under  the  new  rules  is  essentially  or¬ 
phaned.  This  abrupt  change  of  behavior  is  probably  acceptable,  and  may  even  be  desirable  in 
some  contexts:  nuhtary  emergencies  for  example.  However,  in  some  contexts  this  abruptness 
would  cause  considerable  difficulty.  In  om  banking  example  for  instance,  there  may  be  occa¬ 
sions  when  a  particular  user  must  complete  a  specific  transaction  before  the  end  of  the  day. 
However,  if  the  pohcy  transition  time  occurs  at  5:00  PM  sharp  and  the  user  needs  an  additional 
fifteen  to  twenty  minutes  to  complete  the  task,  then  this  implementation  of  the  pohcy  adap¬ 
tation  would  hinder  bank  employees  from  completing  vital  tasks.  This  wovild  be  unacceptable 
under  this  scenario. 


Security  Although  the  security  database  is  a  critical  object  that  should  be  protected  from 
unauthorized  modification,  a  clear  security  risk  is  that  the  security  database  file  could  be 
changed  inappropriately  while  the  system  is  in  operational  mode.  Intuitively,  the  security 
database  is  more  susceptible  to  replacement  or  modification  during  operation  tha  n  the  database 
(and  system)  would  be  to  attacks  conducted  between  successive  boots  of  the  system.  If  subverted 
software  could  replace  the  intended  database  with  a  different  file,  the  system  would  enforce 
the  wrong  pohcy. 

A  clear  security  concern  for  this  type  of  change  of  pohcy  is  who  can  authorize,  authenticate, 
and  execute  the  pohcy  change.  In  the  DTOS  prototype,  authority  to  reload  the  security’  pohcy 
is  restricted  to  subjects  that  have  the  permission  ss-genJoad4>olicy.  Authorization  to  operate 
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subjects  with  this  permission  can  be  restricted  to  certain  processes,  to  roles,  or  to  sets  of 
individuals  with  other  security  mechanisms. 


Assurability  The  immediacy  of  the  transition  of  this  method  provides  for  the  greatest  ask¬ 
ance:  the  users  always  know  exactly  which  poUcy  is  the  current  policy.  As  will  be  shown  below, 
this  is  not  always  the  case  with  other  methods.  There  could  also  be  some  concert^  about  the 
flow  of  information  across  transitions,  but  this  concern  exists  for  all  methods  of  policy  adapte- 
tion.  Furthermore,  some  of  the  formal  modeling  and  proofs  might  be  relatively  easier  than  for 
more  complex  transitions. 


Reliability  A  tangible  concern  is  that  if  the  database  file  has  become  corrupted,  then  the 
Security  Server  will  not  be  able  to  read  it.  The  effect  of  this  is  that  the  Security  Server  dies, 
and  the  system  is  left  without  any  Security  Server  at  all.  Not  only  would  the  system  not  w  ^le 
to  enforce  the  new,  intended  policy,  but  the  system  would  have  difficulty  running  at  all.  The 
microkernel  and  other  processes  that  can  cache  permissions  computed  by  the  Security  Server 
would  rely  solely  on  the  permissions  that  had  been  cached  up  to  the  time  that  the  Security 
Server  went  down 

Both  the  security  and  reliability  concerns  could  be  ameliorated  by  placing  a  checksum  (or 
computing  a  hash  of  even  a  digital  signature)  over  the  security  database;  in  this  case,  the 
Security'  Server  could  be  implemented  so  as  not  to  read  in  the  new  database  unless  the  checksum 
can  be  verified. 


Performance  This  is  the  second  fastest  method  for  changing  policies.  During  perform^ce 
testing,  a  typical  transition  time  (median)  required  2.985  seconds,  and  no  transition  required 
more  tfian  3.970  seconds.  Although  this  might  not  be  as  fast  as  necessary  in  a  real-time  embed¬ 
ded  system,  this  would  be  more  than  satLsfactoiy  in  systems  such  as  the  banking  application 
mentioned  in  the  introduction. 

In  Figure  5-16,  the  abscissa  (x-value)  represents  the  time  in  seconds  required  to  reload  the 
policy  while  the  ordinate  (j/- value)  represents  the  percentage  of  observations  less  than  or  equal 
to  the  r-value. 


5.4.2  Expanding  the  Database  and  Security  Server  State 

In  this  method  of  transition  between  policies,  when  the  Security  Server  loads  its  initial  security' 
database,  all  of  the  permissions  allowed  under  all  modes  of  operation  would  be  initialized  in 
the  Security  Serveris  internal  memoiy.  A  mechanism  intern^  to  the  Security  Server  would 
allow  it  to  change  policy  without  having  to  read  a  new  security  database.  Thus,  policy  changes 
could  be  triggered  by  a  variety  of  events.  The  policy  could  change  based  on  the  time,  or  when 
processes  complete  certain  tasks  or  invoke  certain  permissions,  or  when  alarms  are  set  off 
by  possible  intrusion  events.  This  method  is  similar  to  the  Reload  Policy  mechanism  above; 
however,  because  of  the  ability  to  change  policies  based  on  triggering  events,  it  has  a  number 
of  advantages  which  are  listed  below. 


Policy  Flexibility  This  method  has  the  same  restrictions  that  the  Reload  Policy  mechanism 
has.  It  is  easiest  for  the  Security  Server  to  alternate  among  policies  which  are  similar.  For 
initial  policies  based  on  Type  Enforcement  or  MLS  access  rules,  the  new  policy  must  also  be 
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Figure  5-16:  The  Cumulative  Distribution  for  100  Trials  of  the  Reload  Policy  Method 


based  on  Type  Enforcement  or  MLS  access  rules.  However,  the  mechanisms  for  changing  policy- 
definition  give  this  method  greater  flexibility  than  the  previous  method. 

For  example,  for  policies  which  change  on  a  regular,  periodic  basis  (recall  the  banking  example 
in  which  a  more  stringent  pohcy  is  enforced  for  after-hours  operation),  a  timing  mechanism 
that  triggers  the  change  of  policy  could  be  added  to  the  Security  Server. 

Another  adaptation  mechanism  could  be  triggered  by  the  use  of  particular  permissions.  For 
example,  when  a  particular  permission  is  requested  and  returned  to  the  requesting  process, 
that  permission  could  be  removed  from  the  Security  Server’s  notion  of  the  allowed  permissions. 
This  would  render  the  permission  as  a  one-time  oifly  permission.  For  example,  in  a  commercial 
application  a  one-time  permission  to  issue  payment  for  a  piorchase  order  would  prevent  double 
payment. 

Similarly,  when  a  particular  permission  is  requested  and  returned  to  the  requesting  process, 
that  permission  could  be  removed  from  the  Security  Server’s  notion  of  the  allowed  permissions^ 
and  one  or  more  could  be  added.  Such  adaptations  cotild  be  chained  together.  For  example,  if 
the  Security  Server  were  applying  Type  Enforcement,  a  process  operating  in  one  domain  might 
be  granted  access  to  a  new  type  and  denied  access  to  an  old  one.  Thus  a  set  of  operations 
could  be  performed  by  a  single  process  in  a  secure  pipeline.  Such  secure  pipelines  are  already 
pessible  ^th  Type  Enforcement,  but  each  operation  is  performed  by  a  separate  process,  each 
running  in  a  unique  domain  (see  [2]  and  [  12]  for  more  details).  This  type  of  mechanism  woiild 
also  be  ideal  for  enforcing  the  security  pohcy  known  as  Chinese  Wall  (see  [20]  for  a  description). 


Functional  Flexibility  Since  the  transition  between  pehcies  during  the  loading  of  a  new  pohcy  is 
essentially  atomic,  this  implementation  could  be  as  harsh  on  running  apphcations  as  the  Reload 
Pohcy  mechanism.  However,  the  database  could  be  expanded  to  include  several  policies  so  that 
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a  policy  transition  could  take  place  with  several  intermediate  policies  during  the  tradition.  A 
phased  transition  of  this  sort  might  allow  some  tasks  to  complete  processing  within  fixed  time 

limits. 


Securiti  The  security  concerns  here  are  the  same  as  for  the  reload  pohcy  mth  -^e  exception 
that  the  security  database  is  read  once  and  only  once  at  mitigation,  and  thus  the  possibihty 
that  an  imtrusted  user  or  process  has  been  able  to  corrupt  it  is  eliminated. 

With  the  expanded  state  of  the  Security  Server,  changes  of  policy  may  ^  rented  automati¬ 
cally  by  the  time  of  day,  as  in  the  banking  example,  or  by  events,  as  m  the  Chi^se  pohc> 
[31.  By  moving  the  authority  for  changing  the  pohcy  from  subjects  to  events,  &e  methods  by 
which  hostile  users  could  alter  the  enforced  policy  change.  If  a  hostile  user  coiJd  tamper  wito 
the  system  clock,  or  force  a  triggering  event,  or  counterfeit  a  triggering  event,  then  he  could 
control  changes  of  policy. 


The  ability  to  “harden  up”  system  defenses  automatically  in  the  event  of  a  possible  intrusion 
also  seems  to  be  a  particular  advantage  not  present  in  the  Reload  Pohcy  mechanism. 


Assurabilit>-  Again,  as  with  the  Reload  Pohcy  Method,  the  immediacy  of  the  transition  of  this 
method  provides  for  good  assurance,  because  the  users  always  know  exactly  which  p(^c>  is 
the  current  pohcy.  However,  as  with  any  pohcy  change,  there  are  concerns  about  the  flow  of 
information  across  transitions.  It  may  be  the  case,  for  example,  that  under  a  more  restnctive 
pohcy  processes  A  and  B  are  not  allowed  to  communicate  with  one  another.  However,  under  a 
more  relaxed  pohcy  they  share  access  to  a  common  object. 

Considering  that  the  pohcy  would  change  given  some  triggering  event  such  as  the  detection  of 
intrusion,  it  might  be  possible  to  capture  this  type  of  pohcy  adaptation  in  the  security  pohcy.  For 
example,  one  might  include  in  the  pohcy  the  requirement  that  the  pohcy  is  hardened  m  specific 
ways  whenever  an  intrusion  is  detected.  Thus  one  could  attempt  to  provide  clear  arguments 
about  the  behavior  of  the  system  with  respect  to  these  requirements. 


Reliability  This  method  is  more  reliable  than  reloading  the  pohcy  because  we  are  not  concerned 
about  the  second  pohcy  being  corrupted  after  boot-time.  However,  this  method  does  make  the 
coding  of  the  Security  Server  more  complex  which  may  cause  unforeseen  problems. 


Performance  Exphcit  performance  numbers  are  not  avEulable  for  this  method.  However,  since 
it  avoids  the  time-consuming  step  of  reading  a  new  database,  it  is  anticipated  to  be  faster  than 
tbe  Reload  Pohcy  Method,  and  expected  transition  times  should  be  less  than  one  second.  Thus, 
it  is  expected  to  be  the  fastest  of  the  four  methods  under  discussion. 

The  microkernel  and  other  processes  can  cache  permissions  to  improve  performance;  so  chang¬ 
ing  pohcy  and  flushing  the  cache  frequently  could  cause  a  minor  performance  drag.  However, 
permissions  in  the  database  can  be  flagged  as  noncacheable.  Thus,  transient  permissions  as 
described  above  could  be  flagged  in  that  way  so  that  the  microkernel  would  not  have  to  flush  its 
entire  cache  as  it  does  for  the  Reload  Pohcy  mechanism.  Similarly,  permissions  in  the  database 
can  be  flagged  as  those  which  cannot  be  flushed.  Thus,  persistent  permissions  could  be  flagged 
so  that  the  microkernel  woiild  not  have  to  flush  those  permissions  from  its  cache  at  ah,  and 
performance  would  not  be  adversely  affected  by  the  adaptation  of  pohcies. 
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5.4.3  Handing  Off  Control  to  a  New  Security  Server 


In  Seoirity  Server  hand-ofij  the  current  Security  Server  passes  the  receive  capability 
for  its  security’  port  to  another  Security  Server  that  implements  a  new  policy.  In  order  to 
accomplish  this,  the  new  Security  Server  is  initialized  while  the  current  Security  Server  is  still 
in  control  of  the  policy  decisions.  The  new  Security  Server  uses  the  command  get..special.port 
to  obtain  the  send  right  to  client  port  of  the  current  Security  Server  wnd  then  issues  the 
transfer  security  .ports  to  the  current  server.  The  current  Security  Server  packages  the 
receive  rights  for  the  its  security  port  along  with  two  other  tables  of  information.  One  contains 
^e  mapping  between  security  contexts  and  SIDs  that  the  current  Security  Server  uses  to 
inteipret  incoming  requests,  and  the  other  is  a  list  of  the  ports  of  processes  which  may  be 
caching  security  permissions.  The  new  Security  Server  needs  the  former  to  interpret  requests 
that  it  receives  regarding  any  processes  or  objects  that  exist  prior  to  the  hand-off.  It  needs 
the  latter  because  it  may  eventually  need  to  teU  these  other  processes  to  flush  their  cached 
permissions.  The  last  action  of  the  current  Security  Server  is  to  teh  all  processes  with  cached 
permissions  to  flush  their  caches.  At  this  point  the  new  Security  Server  cjiri  compute  access 
permissions,  and  the  microkernel  and  any  other  processes  that  enforce  these  permissions  can 
enforce  the  new  security  policy. 


Figure  5-17;  Security  Server  Hand-Off 


In  order  to  be  able  to  process  new  requests  for  permission  computations,  the  new  Security 
Server  must  be  able  to  interpret  the  requests.  As  mentioned  above,  the  old  Security  Server 
sends  the  appropriate  information  for  the  new  Security  Server  to  match  contexts  to  SIDs. 
However,  the  new  Security  Server  has  some  knowledge  of  security  contexts  prior  to  receiving 
tlus  information  finm  the  old  Security  Server;  so  it  must  reconcile  its  understanding  of  contexts 
with  the  mapping  information  received  from  the  old  Security  Server.  It  also  must  create  new 
SDs  for  any  new  contexts  which  were  not  recognized  by  the  old  Security  Server.  For  example, 
if  both  the  new  Security  Server  and  old  Security  Server  are  implementing  Type  Enforcement 
and  there  are  new  domains  as  part  of  the  new  policy,  each  new  domain  must  receive  a  SID. 
Similarly,  if  the  hand-off  occurs  in  order  to  implement  dynamic  lattices  as  part  of  an  adaptive 
MLS  policy,  any  new  levels  must  receive  SIDs.  Once  the  new  Security  Server  has  completed 
this  reconciliation,  the  old  Security  Server  can  shut  down. 
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Policy  Flexibility  The  greatest  strength  of  the  hand -off  method  is  that  one  can  enforce  a  global, 
radical  change  of  policy.  The  new  Security  Server  can  implement  a  very  different  pohcy  from 
the  one  that  is  enforced  before  the  hand-off.  As  discussed  above  in  Section  5.4.1,  the  only 
impediment  to  rbanging  the  policy  in  a  radical  way  is  the  labeling  of  objects  and  processes  with 
the  appropriate  set  of  attributes  which  can  be  interpreted  by  both  the  new  and  old  Security- 
Servers.  In  other  words,  radically  different  policies  may  require  essentially  disjoint  sets  of 
attributes  which  the  system  designers  glue  together  for  the  context  of  any  single  entity. 


Functional  Flexibility  In  essence  this  method  is  not  different  from  the  Reload  PoHcy  option. 
Changes  to  the  security  policy  are  global  and  atomic.  The  same  problems  exist  in  this  method 
as  the  for  Reload  Policy  for  situations  where  a  harsh  change  of  policy  is  undesirable,  as  in  the 
banking  example. 


Security  Some  of  the  same  security  advantages  and  concerns  exist  here  as  for  the  Reload 
Policy  method.  As  with  the  Reload  Policy  method,  the  users  always  know  exactly  which  policy 
is  the  current  policy.  However,  if  the  new  Security  Server  has  to  initialize  from  some  static  file 
or  security  database,  there  is  always  the  risk  that  it  could  be  subverted.  Another  possibility  is 
that  the  code  for  a  new  Security  Server  could  be  subverted  as  well  and  that  a  mahcious  Security 
Server  coxild  end  up  in  control  of  the  permission  decisions. 

Also  the  question  of  who  can  authorize,  authenticate,  and  execute  the  policy  change  exists  for 
this  method.  The  Security  Server  will  hand  off  the  security  port  to  ^e  new  server  when  it 
receives  the  comma  nd  SSIjtransferjsecurity4>orts  on  its  security  port.  Just  as  in  the  case  of  the 
authority  to  reload  the  policy,  the  permission  to  issue  this  command  is  restricted  to  subjects  that 
have  the  permission  ss^enJoad4>olicy.  Authorization  to  operate  subjects  with  this  permission 
can  be  restricted  to  certain  roles  or  to  sets  of  individuals  with  other  security  mechanisms.  The 
additional  concern  here  is  that  the  security  port  is  transferred  to  the  correct  subject,  the  new 
Security  Server. 


Assurability  Again,  as  with  the  previous  two  methods,  the  transition  of  this  method  provides 
for  reasonably  good  assurance.  The  users  know  almost  exactly  which  policy  is  the  current 
policy,  but  there  is  a  certain  lag  time  while  the  port  rights  are  in  transition.  This  may  lead  to 
the  necessity  of  using  temporal  logics  and  arguing  about  eventuality. 


Reliability  Unfortunately  the  hand -off  procedure  on  the  DTOS  prototype  is  delicate,  and  this 
is  its  greatest  weakness.  The  unreliability  may  be  an  artifact  of  the  DTOS  prototype  and  the 
Lites  server  that  is  used  to  provide  the  light-weight  microkernel  with  services  that  allow  one 
to  use  UNIX  applications  on  DTOS.  The  combination  of  the  microkernel,  Lites  server,  end  the 
Security  Server  is  prone  to  paging  errors  and  deadlocks.  To  avoid  these  errors,  the  microkernel 
must  have  a  sufiBdent  set  of  permissions  hard-coded  into  its  cache  (these  permissions  are  not 
flushed  from  the  microkernel).  Some  of  the  permissions  required  by  the  new  Security  Server 
to  complete  the  hand -off  must  be  in  the  hard-coded  cache  before  the  transition  is  initiated. 

For  example,  the  Security  Server  has  pageable  memory.  During  the  hand-oflf  the  Security 
Server  may  start  using  new  areas  of  memory  while  processing  a  security  request  from  the 
microkernel.  If  a  page  fault  occurs,  then  the  Security  Server  itself  wiU  request  service  fium 
the  microkernel.  If  the  microkernel  has  not  cached  the  permission  required  by  the  Security- 
Server,  it  must  in  turn  request  a  security  computation  from  the  Security  Server.  However,  the 
Security  Server  is  blocked  on  the  request  to  the  microkernel  for  service,  and  the  microkernel 
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cannot  complete  its  request  without  the  security  computation  &um  the  Security  Server.  What 
makes  these  types  of  events  impredictable  is  the  esdstence  of  other  processes  on  the  system 
that  may  request  services  from  the  Lites  server  while  the  security  port  rights  are  in  transit. 
The  new  Security  Server  depends  on  the  Lites  server  for  services,  but  a  thread  of  execution  in 
the  Lites  server  can  be  waiting  for  a  security  computation  creating  the  deadlock. 


Performance  This  is  the  slowest  of  the  methods  tested.  During  performance  testing,  a  typical 
transition  time  (median)  required  4.900  seconds,  and  all  transitions  fell  with  the  range  of  4.820 
to  5.010  seconds.  This  might  not  be  as  fast  as  the  Reload  Policy  method,  but  once  again  this 
would  be  more  than  satisfactory  in  systems  such  as  the  banking  application  mentioned  in  the 
introduction 

In  Figure  5-18,  as  in  Figure  5-16,  the  abscissa  represents  the  time  in  seconds  required  to 
hand  off  the  security  port  rights  to  the  new  Security  Server,  while  the  ordinate  represents  the 
percentage  of  observations  less  than  or  equal  to  the  corresponding  elapsed  time. 


Figure  5-18:  The  Cumulative  Distribution  for  10  Trials  of  the  Hand-Off  Method 


5.4.4  Adding  Security  Servers  for  New  Tasks 

The  final  method  for  changing  the  security  policy  is  to  create  a  set  of  task -based  Security 
Servers.  With  this  method  there  may  be  more  than  one  Security  Server  computing  access 
decisions  for  the  microkernel  and  other  chents,  each  defining  a  separate  set  of  security  rules. 
WTnle  the  microkernel  is  enforcing  multiple  policies,  each  task  on  the  system  is  associated  with 
one  and  only  one  Secxiiity  Server,  and  therefore,  each  task  operates  under  a  single  policy.’'^  In 

^^']t  ie  Dot  exactly  true  that  each  task  has  only  one  Security  Server,  but  it  ie  a  uaeful  fiction  for  the  time  being  The 
bottom  line  ie  that  there  ie  only  one  way  for  each  accese  request  to  be  computed  by  the  entire  aet  of  Security  Servers- 
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the  three  previously  described  methods,  all  tasks  operate  under  a  single,  monolithic  pohcy. 

For  this  method  we  introduce  a  new  global  variable:  the  Security  Server  Stack' '  Each  entry  in 
the  stack  consists  of  a  data  structure  containing  the  security  and  client  ports  for  each  Security 
Server.  At  boot  time,  the  initial  Security  Server  uses  the  set  jspecial-port  command  to  enter 
the  security  and  chent  ports  to  the  stack  in  the  0-th  place.  Another  global  variable,  curr_ss. 
points  to  the  0-th  entry  in  the  stack  to  indicate  that  the  initial  Security  Server  is  the  current 
Seciirity  Server.  ^Tien  another  Security  Server  is  created,  it  also  enters  its  ports  to  the  stack 
at  the  first  available  entry,  and  currjss  is  incremented  to  the  next  position  in  the  stack. 

Each  task  has  a  pointer  labeled  ss.ptr  that  identifies  the  Security  Server  that  defines  the 
policy  under  which  the  task  is  running  When  tasks  are  created,  BS-ptr  is  set  to  curr^s  by 
default,  though  the  parent  task  may  cause  the  value  of  ss.ptr  for  the  new  task  to  be  set  to 
the  parents  Security  Server.  Like  any  other  process,  each  new  Security  Server  itself  operates 
under  the  policy  defined  by  a  Security  Server  which  precedes  it  in  the  stack  (the  Security  Server 
immediately  preceding  it  would  be  the  default).  When  the  microkernel  receives  a  recfuest.  it 
checks  its  cache  for  the  permission.  Permissions  in  the  cache  are  identified  by  a  triple:  two 
SIDs,  as  before,  and  the  ss.ptr  of  the  requesting  subject.  If  the  permission  is  not  in  the  cache, 
it  sends  a  request  to  the  Seoirity  Server  assigned  to  the  requesting  task.  The  Security  Server 
computes  the  requested  security  access,  unless  it  receives  a  request  with  a  context  that  it 
does  not  understand.  If  the  Security  Server  cannot  resolve  the  SIDs  into  security  contexts,  it 
forwards  the  request  to  its  own  Security  Server.'^  The  request  is  passed  down  the  stack  until 
some  Security’  Server  is  able  to  resolve  the  SIDs  into  contexts  and  a  security  computation  can 
be  made. 


Figure  5-19:  Security  Server  Stack  Before  “Push’" 


Figure  5-20:  Security  Server  Stack  After  “Push” 

This  method  for  rbanging  the  security  policy  is  the  most  robust  and  possibly  the  most  flexible 
method  of  the  four  methods  discuss^  in  this  study.  However,  the  additional  flexibility  and 

other  processee,  each  Secanty  Server  refers  to  a  preceding  Security  Server.  If  each  Security  Server  in  the 
stack  refers  to  its  immediate  predecesBor  in  the  stack,  then  it  is  truly  a  stack -like  implementation.  If  the  Security 
Servers  in  the  “stack"  refer  to  servers  older  thnn  their  immediate  predecessors,  then  a  gr^h  of  the  dependencies  could 
be  more  accurately  described  as  a  “tree." 

^^This  is  the  reason  that  tasks  do  not  necessarily  have  only  one  Security  Server. 
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reliability  of  enforcing  multiple  security  policies  may  come  with  an  increased  cost  for  assuring 
the  security  of  the  system. 


Policy  Flexibility'  This  method  for  changing  policy  provides  the  capability  for  considerable  flex¬ 
ibility  for  changing  the  policy.  However,  as  new  Security  Servers  are  created,  only  new  tasks 
operate  under  the  new  policy  rules;  so  changes  to  the  system-wide  policy  are  local  rather  than 
global.  In  other  words:  you  can’t  teach  an  old  dog  new  tricks,  because  old  tasks  will  continue 
to  run  under  the  policy  defined  by  the  old  Security  Server. 

There  is  the  possibility  that  the  stack  could  be  augmented  by  using  one  of  the  other  policy 
changing  mechanisms  to  force  old  tasks  to  run  under  a  new  policy.  For  example,  if  there  are 
two  servers  in  the  stack  at  positions  0  and  1,  the  Security  Server  at  position  0  could  hand  off" 
to  a  third  Security  Server  which  is  identical  to  the  Security  Server  in  position  1.  Thus,  both 
servers  operating  would  define  the  same  policy,  and  the  microkernel  would  be  enforcing  only- 
one  policy’  rather  than  two.  (In  fact,  the  first  two  servers  could  then  exit,  all  tasks  with  pointers 
to  the  second  Security  Server  would  be  re-directed  to  the  server  at  position  0  (the  third  server), 
and  the  system  woiild  only  have  one  Security  Server  as  well  as  one  policy.) 


Functional  Flexibility'  Functional  flexibihty  is  the  greatest  strength  of  the  Security  Server  stack 
method.  Allowing  running  processes  to  run  under  their  original  policy  is  a  way  of  “grandfather¬ 
ing’'  in  their  allowed  accesses.  Thus,  in  o\ir  banking  example,  if  some  user  is  actively  working 
on  a  task  at  5:00  p.m.  which  must  be  completed,  but  the  bank’s  security  policy  is  set  to  change 
to  a  more  restrictive  policy  at  that  time,  the  user  would  be  allowed  to  continue  his  task  because 
the  task  is  operating  under  the  less  restrictive  policy.  However,  any  attempt  by  a  user  to  create 
new  tasks  after  5:00  pm  woxdd  be  subject  to  the  new,  more  restrictive  policy 


Security  This  method  is  a  double-edged  sword.  It  is  possible  that  certain  tasks  which  need  to 
be  highly  constrained  coiild  op>erate  under  more  restrictive  policies  than  is  generally  allowed. 
This  could  be  an  advantageous  design  for  increasing  security.  However,  once  a  task  is  granted 
a  permission  to  perform  some  operation  it  is  allowed  to  keep  it,  even  if  another,  more  restrictive 
Security  Server  is  pushed  onto  the  stack.  Thus,  in  the  event  of  an  intrusion,  a  rogue  process 
which  has  gained  unauthorized  access  to  system  resources  may  be  able  to  continue  vinchecked. 
Thus,  the  gains  made  for  functional  flexibility  allow  for  a  loss  of  security.  In  order  to  harden 
up  the  defenses  of  a  system  hke  this,  it  would  be  necessary  to  graft  another  method  of  policy 
change  on  top  of  this  one. 


Assurability  Coordinating  the  necessary  elements  to  implement  this  method  could  be  a  night¬ 
mare  for  system  designers  and  for  any  attempts  to  provide  formal  assurance  evidence.  Fur¬ 
thermore,  there  woiild  be  multiple,  overlapping  security  policies.  One  could  not  make  broad 
global  statements  about  the  behavior  of  the  system  and  the  rules  in  place  at  any  given  time; 
however,  one  may  make  statements  on  a  per  task  basis.  For  this  method,  it  may  be  acceptable 
to  do  this,  and  it  would  even  reduce  the  necessity  of  having  to  use  temporal  logics  and  having 
to  make  difficult  arguments  about  eventuality. 


Reliability  This  method  improves  upon  the  Hand-off  Method  for  reliability  because  there  is  no 
vulnerable  moment  when  the  rights  for  the  security’  port  are  in  transit.  It  is  also  more  reliable 
t.ban  the  Reload  Policy  Method  because  the  top  Security’  Server  in  the  stack  wiU  stiU  be  able 
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to  make  security-  computations  even  if  new  Security  Sen,’ers  fail  to  initialize  due  to  corrupted 
security’  databases. 


Performance  Explicit  performance  numbers  are  not  axmlable  for  this  method.  However,  it  is 
anticipated  to  be  as  fast  or  faster  than  the  Hand-off  Method,  and  expected  tradition  times 
should  be  between  four  and  five  seconds.  The  greatest  factor  in  the  performaMe  for  Stack 
Method  is  the  loading  of  the  large  executable  for  creating  a  new  server  to  push  onto  the  stock, 
but  this  is  also  true  of  the  Hand-off  Method.  The  Hand-off  Method  is  slower  tecause  the  rights 
to  the  security  port  have  to  be  transferred  from  one  server  to  the  other.  This  is  quicker  than 
loading  the  executable  for  the  new  server,  but  adds  an  extra  wait. 


5.5  Conclusions 

For  security  architectures  which  separate  the  definition  of  the  policy  from  its  enforcement, 
the  solution  space  for  implementing  adaptive  security’  policies  is  large.  From  the  entire  range 
of  such  implementations,  this  study  has  examined  four  possible  methods  which  have  been  , 
implemented,  or  partially  implemented,  for  the  DTOS  prototype  by  Secure  Computing.  Each 
implementation  has  strengths  and  weaknesses.  The  criteria  for  evaluating  these  methods 
are  described  in  greater  detail  above,  but  the  trade-offs  are  encapsulated  in  Table  5-7  below. 
From  the  table  the  Stock  Method  and  the  Expanded  State  Method  appear  to  be  the  most 
attractive  options  for  implementing  adaptive  security,  but  which  choices  one  makes  depends 
on  the  eventual  application  for  the  implementation  as  suggested  below. 


Implementati  ons 


Criteria 

Reload 

Policy 

Extend¬ 
ed  State 

"Han-dT- 

Off 

Server 

Stack 

Poliej’  FlexibiLty 

fair 

^ood 

fair 

exceUent 

FxinctionaJ  Flexibility 

poor 

£Ood 

fair 

exceUent 

Security 

good 

exceUent 

fair 

poor 

Abbut  ability 

ezceUent 

good 

fair 

poor 

Reliability 

fair 

excellent 

poor 

good 

Performance 

good 

excellent 

poor 

fair 

Table  5-7;  Summary  of  Trade-Offs 


^Mien  applied  appropriately,  the  Reload  Policy  and  Expanded  State  methods  are  the  lightest 
weight  implementations  a^  provide  good  features  for  a  narrow  subset  of  applications.  In 
particular,  the  key  features  of  these  two  methods  are  that  they  allow  the  Security  Server  to 
reload  a  database,  but  they  do  not  alter  the  algorithms  by  which  the  Security  Server  makes  its 
security  computations.  The  database  and  Security  Server  implementation  for  the  Expanded 
State  method  has  the  potential  for  becoming  complex.  The  additional  complexity  posed  by 
this  work  may  make  alternate  methods  for  implementation  more  attractive.  The  Expanded 
State  method  is  best  left  to  small,  incremental  changes  to  the  policy.  By  comparison  the 
Reload  Policy  Method  is  probably  not  an  attractive  option  for  systems  in  which  there  are  large 
numbers  of  gmall  changes  to  the  policy  databases  since  each  change  of  policy  would  require  its 
ovm  database,  and  the  issue  of  scalability  may  be  burdensome. 

The  other  two  methods,  the  Hand-Off  and  the  Stock  Methods,  allow  for  changes  to  the  al¬ 
gorithms  for  computing  permissions,  and  this  is  what  accoimts  for  a  greater  degree  of  pohcy 
flexibility.  Because  of  the  multiple  points  of  control,  the  Stock  Method  offers  the  greatest 
functional  and  pohcy  flexibhity,  and  the  inheritance  structure  of  the  parent-child  relationships 
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between  Security  Servers  ofifers  the  ability  to  grandfather  permissions  for  running  appHca- 
tions.  However,  that  very  same  asset  is  a  liability.  Policy  changes  under  the  Stack  Method 
are  local,  not  global.  Thus,  it  is  not  possible  to  revoke  permissions  using  that  method  alone. 
Furthermore,  depending  on  the  number  of  policies  supported  on  the  system,  the  Stack  Method 
holds  the  potential  for  being  the  heaviest  weight  implementation. 

hiot  addressed  in  the  discussion  of  individual  implementations,  nor  in  Table  5-7,  is  the  pos- 
sibihty  of  mixing  and  matching  the  four  methods  to  capture  the  best  security  features  of  one 
method  with  the  best  flexibility  features  of  another.  For  example,  one  might  combine  the  Stack 
and  Hand-OfiF  Methods  in  the  following  way.  Tasks  would  operate  under  task -based  policies 
with  the  Stack  Method  up  to  a  certain  point  in  time,  allowing  for  local  changes  to  the  |)olicy 
based  on  roles  and  tasks,  and  then  a  server  might  hand  off  to  its  parent  and  shut  down.  For 
example,  in  the  banking  application  in  which  the  more  restrictive  nighttime  policy  is  the  child 
of  the  less  restrictive  daytime  policy  (i.e.,  the  stricter  Security  Server  is  pushed  onto  the  stack 
at  5  PM),  the  nighttime  server  could  hand  off  to  its  parent  the  following  morning  at  8  AM  and 
shut  down.  Similarly  one  might  follow  the  Hand-Off  or  Stack  Methods  with  a  Reload  Pohcy  to 
change  the  internal  tables  of  a  Security  Server  without  changing  the  fundamental  algorithms 
by  which  it  operates. 
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Section  q 

Summary 


6.1  Conclusions 

Each  major  section  of  this  paper  is  accompanied  by  a  subsection  of  conclusions.  The  following 
is  a  thumbnail  sketch  of  more  detailed  conclusions  which  can  be  found  there. 


Tranquility'  Study 

The  tranquility  study  listed  scenarios  requiring  adaptive  scenarios  and  common  tranquihty 
assumptions  made  about  non-adaptive  systems.  The  study  discussed  specific  scenarios  requir¬ 
ing  adaptive  security  and  the  tranquihty  assumptions  that  such  scenarios  wo^d  violate.  One 
Sse  of  particular  interest  that  was  investigated  was  dynamic  lattices,  wher^  level  POSet  i 
not  tranquil.  The  study  proposes  two  methods  for  representing  a  secun^  lattice  which  would 
support  inclusion  of  extra  levels  and  a  pohcy  for  recovering  from  a  period  of  pohcy  relaxation. 

One  method  for  representing  the  security  lattice  is  the  usual  methc^  of  co^inii^  levels  ^ 
categories  In  this  method  a  number  of  artificial  categories  are  added  wi^out  chan^  the 
number  of  recognized  labels  (points  in  the  lattice)  and  without  changing  ^e  pai^  orfe^^ 
As  manv  artificial  categories  may  be  added  as  there  are  existing  lattice  pomts  so  that  new  pomts 
can  be  added  to  the  lattice.  New  security  labels  are  constructed  through  the  manipulation  of 
the  expanded  set  of  categories. 

The  second  method  for  representing  the  security  lattice  uses  the  local  dominance  suture. 
Since  a  security  lattice  is  a  directed  graph,  the  relative  location  of  each  pomt  m  the  lattice  is 
described  by  listing  all  of  the  other  points  in  the  lattice  that  are  directly  above  it  ^  ^ctiy 
below  it.  It  suffices  to  list  only  those  points  directly  above  or  those  points  d^ctly  ^lo^so 
there  is  some  redundance  in  the  description.  However,  new  points  may  be  added  to  the  lattice 
simply  by  listing  the  points  in  the  original  lattice  between  which  the  new  pomts  will  exist. 

The  high-water  mark  confidentiality  audit  policy  corresponds  to  a  type  of  integrity  policy 
way  that  the  Bell  and  LaPadula  confidentiahty  pohcy  corresponds  to  the  Biba  integrity  model. 
It  adds  a  contamination  label,  which  is  drawn  from  the  same  set  of  labels  as  the  secnmty 
labels  to  subjects  and  objects.  During  a  period  of  pohcy  relaxation,  as  a  subject  or  an  object 
is  exposed  to  entities  with  a  higher  contamination  label,  its  contamination  label  ch^es  to 
match-  therefore  the  contamination  label  increases  monotonically  to  record  the  possible  level 
of  contemination  for  that  subject  or  object  At  the  time  of  recovery,  subjects  or  objects  whose 
contamination  label  is  different  from  their  security  label  can  be  audited  to  verify  the  actual 
contamination  of  that  entity. 

The  tranquihty  study  also  examined  a  set  of  typical  tasks  performed  to  provide  formal  assur^e 
evidence  and  considered  how  these  specific  tasks  would  be  affected  by  the  loss  of  tranquihty.  The 
tasks  considered  include  pohcy  modeling,  formal  specification,  proofs  of  security  requirements 
based  on  formal  specification,  spec-to-code  analysis,  and  covert  channel  analysis.  A  conclusion 
which  crosses  all  of  the  boundaries  of  this  analysis  is  that  it  may  be  necessary  to  formalize 
the  security  pohcy  or  write  specifications  using  temporal  logic.  The  use  of  such  logics  makes  it 
difficult  to  write  both  the  formal  model  of  the  security  pohcy  and  the  formal  specification  of  the 
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system.  Consequently,  reasoning  about  the  requirements  fiem  the  sp>ecifications  is  also  more 
difficult.  Policies  using  temporal  or  real-time  logics  would  be  likely  to  be  less  comprehensible 
in  global  terms.  Specifications  may  never  be  able  to  accurately  model  some  behaviors.  Proofs 
that  ai^e  about  eventuality  and  fairness  are  difficult.  Difficult  specifications  make  spec-to- 
code  more  difficult.  Finally,  the  current  state-of-the-art  in  covert  channel  analysis  does  not 
encompass  adaptive  security';  there  is  no  theory  for  conducting  such  an  analysis,  and  existing 
tool  support  assumes  a  static  jxilicy.  However,  one  conclusion  from  this  jxirtion  of  the  study 
is  that,  while  some  generalizations  can  be  stated  about  how  the  formal  assurance  might  need 
to  change,  some  of  these  tasks  need  to  be  j)erformed  for  concrete  system  in  order  to  fully 
understand  the  full  impact  that  adaptive  security  has  on  assurance. 

Audit 

The  investigation  of  audit  techniques  produced  two  promising  results.  Each  of  these  results 
arises  from  particular  problems  faced  during  the  coUection  and  interpretation  of  audit  infor¬ 
mation.  The  first  problem  is  that  by  auditing  fine-grained  permission  checks,  it  is  difficult  to 
relate  these  to  a  single  chain  of  execution.  The  second  problem  is  that  permission  checks  are 
at  too  low  a  level  to  be  related  to  functional  operations. 

A  solution  for  the  first  problem  was  the  introduction  of  a  tracing  identifier  (TID).  The  TID  is 
added  to  the  microkernel  thread  structure,  and  thus  it  accompanies  a  series  of  requests  through 
the  machine  as  threads  pass  messages  requesting  service  of  other  entities.  The  TID  is  included 
in  the  audited  information,  thus  allowing  the  audit  manager  to  organize  audited  events  into 
sets  from  which  higher-level  actions  can  be  inferred  and  analyzed. 

A  solution  for  the  second  problem  is  to  alter  the  microkernel  to  monitor  service  requests  made 
of  other  servers.  Thus,  the  microkernel  may  be  described  as  “snooping"  the  messages  sent  to 
those  servers  to  look  for  auditable  events. 

One  other  result  of  the  work  on  auditing  is  that  audit  events  may  be  used  as  triggers  for  policy 
adaptation.  Some  minor  changes  were  made  to  the  Security  Server  and  the  Audit  Daemon  so 
that  when  certain  events  are  audited,  the  Audit  Daemon  can  inform  the  Security  Server  which 
then  changes  the  definition  of  the  security  policy.  This  could  be  useful  for  hardening  a  policy 
following  intrusion  detection  or  for  implementing  a  commercial  security  policy  like  Chinese 
Wall. 


Database  Tools 

Maintaining  security  database  files  for  any  complex  system  requires  the  use  of  some  man¬ 
agement  tools.  A  typical  method  for  creating  and  maintaining  security  databases  is  to  write 
Reifications  for  the  database  in  a  specialized  language  and  to  use  tools  to  compile  the  spec¬ 
ifications  into  the  actual  database  that  the  system  uses  for  making  access  computations.  The 
existing  procedure  for  DTOS  has  been  to  write  several  files  specifying  the  security  policy  anrl 
then  to  run  the  files  through  the  M4  macro  processor  and  some  Perl  scripts  to  generate  access 
vectors.  One  problem  with  this  method  is  that  the  macros  used  to  logically  group  permissions 
do  not  afford  simple  modifications.  Furthermore,  both  the  input  and  output  files  use  syntaxes 
which  are  difficult  to  read  and  interpret. 

For  this  task,  a  tool  with  a  graphical  user  interface  (GUI)  for  specifying  the  security  database 
was  designed  and  implemented.  The  advantages  of  such  a  tool  are  two-fold.  First,  the  tool 
supports  the  maintenance  and  modification  of  security  database  information  which  is  a  costlv 
and  error-prone  operation  when  performed  “by  hand."  Second,  by  using  a  tool  to  specify  the 
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setrurity  database  directly,  tide  user  need  not  learn  a  s^cification  language.  The  GUI  tool 
provides  the  mpanc  for  creating  and  modifying  the  policy  along  with  the  compilation  tools 
needed  to  generate  access  vectors. 

Four  primary  re(juirements  were  identified  for  the  tool. 

1.  The  tool  must  permit  grouping  of  permissions  into  hierarchical  sets. 

2.  The  tool  must  support  specific  adaptation  methods. 

3.  The  tool  must  allow  for  upgrading  existing  DTOS  policj-  files. 

4.  The  tool  must  minimixe  modification  to  the  Security  Server  by  using  a  format  for  output 
files  which  are  compatible  with  existing  files. 

The  first  requirement  is  a  general  requirement  which  might  be  imposed  for  any  specification 
tool.  The  second  requirement  is  spe<^cally  related  to  the  nature  of  adaptive  securitj'.  The 
final  two  requirements  were  imposed  because  of  existing  constraints  from  the  development 
environment. 

The  tool  was  developed  using  the  Windows  95/Windows  NT  system  because  of  the  wealth  of 
tools  available  for  this  platform.  The  tool  developed  supported  a  policy  adaptation  method 
using  time-of-day  adaptations. 


Trade-Off  Study 

Four  possible  implementations  of  adaptive  security  were  compared  relative  to  six  criteria. 
The  implementations  considered  included  reloading  the  security  policy  of  the  Security  Serv’er, 
expanding  the  state  of  Security  Server  to  include  more  than  one  policy,  forcing  the  security 
Server  to  band  off  control  to  another  Security  Server,  and  implementing  concurrent  Security- 
Servers  each  defining  the  security  policy  for  a  subset  of  the  running  processes.  The  criteria 
include  the  flexibility  to  change  pohcy,  the  effects  on  running  processes,  security,  assurability, 
reliability,  and  performance. 

The  trade-off  study  does  not  recommend  a  single  solution  for  adaptive  security  policies;  instead 
the  results  indicate  that  developers  have  a  range  of  choices  which  allow  them  to  pick  one  or 
more  solutions  which  best  fit  their  needs.  In  particular,  a  system  with  a  single  Security  Server, 
can  be  used  for  simple  pohcy  transitions.  This  works  especially  well  for  pohcy  transitions  that 
must  occur  globally  and  quickly.  Such  policy  adaptations  may  also  pro-vide  greater  security 
in  the  face  of  intrusion  detection.  More  complicated  implementations  are  needed  for  other 
scenarios.  For  example  miiltiple,  task -based  security  servers  can  be  employed  with  the  benefit 
that  pohcy  changes  are  local  in  a  way  that  would  support  grandfathering. 


6.2  Lessons  Learned 

The  main  lesson  learned  fium  exploring  the  impact  on  ass\irance  from  the  loss  of  tranquility 
assumptions  wras  that  a  number  of  formal  assurance  tasks  have  to  be  performed  on  an  actual 
system  with  an  adaptive  pohcy  in  order  to  fully  understand  the  topic.  Concrete  results  will 
only  be  gained  from  working  on  a  concrete  system 

The  DTOS  Medical  Demo  was  analyzed  to  get  a  more  concrete  xmderstanding  of  the  impact  of 
the  loss  of  tranquility.  However,  since  the  assurance  tasks  for  this  example  system  were  not 
actually  carried  out,  the  analysis  was  still  quite  general. 

In  assessing  the  usefulness  of  audit  data,  it  was  learned  that  auditing  the  low-level  permission 
checks  in  the  microkernel  are  not  sufficient  to  trace  the  flow  of  information.  ^Tule  auditing 
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fine-gTciiiied  permission  checks  in  the  entire  system  would  be  sufficient,  it  would  also  be  costly. 
Since  the  Lites  UNIX  server  has  some  security  features,  auditing  permission  checks  by  the 
microkernel  and  the  Lites  server  would  be  sufficient  for  a  larger  set  of  operations  though 
it  is  clearly  not  sufficient  for  some  cases.  In  particular,  Oracle^*^,  a  database  management 
apphcation,  enforces  its  own  permission  checking  and  does  not  rely  upwn  the  file  system. 

Two  of  the  requirements  stated  for  developing  the  database  tools  are  somewhat  incompatible. 
Namely,  the  goals  of  specifying  the  poHcy  at  a  level  which  is  high  enough  to  be  understand  able 
and  yet  to  maintain  control  of  permissions  at  a  low  level. 

In  the  trade-off  study,  it  was  learned  that  p>erformance  was  a  relatively  minor  issue  when 
considering  the  criteria  on  which  to  base  choosing  an  implementation  of  adaptive  security. 
The  pohcy  and  functional  fiexibihty  of  the  various  methods  were  more  important  issues.  The 
appropriateness  of  the  implementation  depended  almost  wholly  on  the  scope  and  types  of  the 
change  required  and  the  needs  of  the  oiganization 


6.3  Future  Work 

Current  work  on  adaptive  security  has  focused  on  theoretical  aspects  of  adaptive  security  poli¬ 
cies  and  on  various  mechanisms  for  implementing  adaptive  security.  Future  work  on  adaptive 
security  pohcies  should  turn  from  the  theoretical  to  the  apphed,  hopefully  by  implementing  a 
demonstration  system.  For  example,  one  might  implement  a  set  of  banking  apphcations  that 
would  operate  under  policies  for  daytime  and  after-hours  processing.  A  demonstration  system 
of  this  type  should  also  be  accompanied  by  formal  assurance  evidence  such  as  a  formal  security 
pohcy.  However,  until  there  is  a  real  system  to  examine,  formal  assiirance  for  adaptive  security 
can  only  be  speculative. 

For  audit,  the  use  of  the  tracing  identifiers  (TIDs)  appears  to  be  a  good  suggestion,  but  they 
have  not  been  tested  in  a  system  in  which  the  administrator  is  attempting  to  recover  from 
relaxed  security.  However,  there  are  other  proposals  for  future  work  beyond  giving  greater 
meaning  nnd  form  to  the  discussion  of  assurance  and  audit. 

The  the  Stack  Method  presented  in  the  trade-off  study  appears  to  be  very  interesting.  Since 
role-based  access  control  (RBAC)  is  a  topic  of  current  interest  in  the  computer  security  com- 
miinity,  further  study  of  the  abihty  of  the  Stack  Method  to  support  RBAC  would  be  beneficial. 
The  inheritance-hke  relationship  between  parent-child  pairs  of  servers  would  be  of  particular 
interest. 

Other  areas  of  future  research  could  include 

1.  automating  tools  for  recovery  from  pohcy  relaxation 

2.  build  a  database  specification  tool  with  event-based  pohcy  adaptation  mechanisms 

3.  implement  more  fully  two  of  methods  described  in  the  Trade-off  Study:  expanding  the 
Security  Server  state  and  the  Security  Server  Stack 
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AppendUc. 

DTOS  Overview 


DTOS  was  designed  around  a  security  architecture  that  separates  enforcement  from  the  def¬ 
inition  of  the  policy  that  is  enforced.  This  architecture  allows  the  system  security  polic}'  to 
be  changed  without  altering  tlie  enforcement  mechanisms.  The  policy  is  defined  as  a  fiinction 
from  the  security  context  of  the  subject  Tnflking  an  access  and  the  security  context  of  the  object 
being  accessed  to  a  set  of  permissions.  Currently,  DTOS  implements  security  contexts  con¬ 
sisting  of  level,  domain,  user,  «>nd  group,  but  the  set  of  attributes  that  form  a  security  context 
is  configurable.  Enforcement  consists  of  determining  whether  the  permissions  specified  by 
the  policy  are  adequate  for  an  access  being  attempted.  The  generality  of  the  DTOS  security 
architecture  has  been  studied  as  part  of  the  DTOS  program  [24].  The  conclusion  of  this  study 
is  that  a  laige  variety  of  security  policies,  useful  for  both  military  and  commercial  systems,  can 
be  implemented. 

The  basic  DTOS  design  is  a  microkernel,  which  implements  several  primitive  object  types 
and  provides  InterProcess  Communication  (IPC),  and  a  collection  of  servers  which  pro\ide 
various  operating  system  services  such  as  files,  authentication,  and  a  user  interface  [8,  16]. 
Of  particular  interest  is  a  Security  Server  that  defines  the  policy  enforced  by  the  microkernel 
and  also  possibly  by  other  servers.  When  a  request  is  made  for  a  service  provided  by  the 
microkernel,  the  microkernel  sends  identifiers  for  the  security  contexts  of  the  subject  and  of 
the  object  to  the  Security  Server.  These  identifiers  are  referred  to  as  security  identifiers  or 
SID’s.  A  context  contains  attributes  about  a  subject  or  object  that  are  necessary  for  making 
security  decisions.  For  example,  the  context  may  contain  the  domain  of  a  subject  or  the  type 
of  an  object,  or  the  level  of  a  subject  or  object.  The  information  that  makes  up  the  context 
is  dependent  on  the  policy;  the  actual  contexts  are  local  to  the  Security  Server  and  are  not 
available  to  the  microkernel.  The  Security  Server  then  computes  permissions  for  the  context 
pair,  as  defined  by  the  policy  that  it  represents,  and  replies  to  the  microkernel.  The  microkernel 
is  ignorant  of  the  context  of  each  entity  since  it  only  enforces  the  permissions  that  the  Security’ 
Server  computes  on  its  behalf.  Finally,  the  microkernel  determines  if  the  permissions  required 
for  the  request  were  present  in  the  reply.  Other  servers  can  communicate  with  the  Security 
Server  in  a  similar  fashion. 

For  example,  a  Security  Server  implementing  an  MLS  policy  might  maintain  subject  and  object 
contexts  consisting  of  a  level.  For  the  microkernel  to  enforce  the  simple  security  and  *-property 
of  the  Bell  and  Lal^diila  model  of  confidentiality,  the  Security  Server  would  only  grant  a  write 
permission  if  the  level  for  the  object  security  identifier  dominates  that  of  the  level  for  the  subject 
security  identifier  and  read  permission  if  the  level  for  the  subject  identifier  dominates  that  for 
the  object  identifier  (both  permissions  a!re  granted  if  the  levels  are  equal).  A  file  server  would 
check  for  write  permission  before  allowing  a  request  to  alter  a  file.  Alternatively,  a  Unix-style 
Security  Server  might  maintain  a  user  and  a  group  for  each  subject  context  and  an  owner, 
group,  and  access  control  bits  for  each  object  context  and  grant  permissions  from  the  access 
control  bits  depending  on  whether  the  tiser  in  the  subject  context  matches  that  of  the  owner 
and  whether  the  groups  match. 

A  prototype  DTOS  microkernel  and  Security  Server  has  been  built  by  Secure  Computing.  The 
microkernel  is  based  on  Mach,  developed  at  Carnegie  MeUon  University  [14,  21].  A  version  of 
the  Lites  UNIX  emidator,  modified  by  the  Government,  provides  secured  UNIX  functionality’. 
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The  object  types  implemented  by  the  microkernel  include  task,  thread,  and  port.  Tasks  and 
threads  represent  the  active  subjects,  or  processes,  in  the  system.  Each  task  has  a  secunt)' 
context  that  is  used  for  securitj^  decisions  involving  that  task.  The  state  of  each  task  includes 
a  virtual  memory  consisting  of  a  set  of  disjoint  memory  regions,  each  of  which  is  backed  by 
a  server  that  is  used  to  swap  pages  of  the  region  in  and  out  of  physical  memory.  Each  task 
contains  a  collection  of  threads,  each  of  which  is  a  sequential  execution,  that  share  the  task  s 
virtual  memory  and  other  resources.  A  server  is  implemented  as  one  or  more  tasks. 

The  ports  are  unidirectiona]  communication  channels  that  the  tasks  use  to  pass  messages. 
Tasks  use  capabilities  to  name  ports,  and  these  are  kept  in  an  EPC  name  space  on  a  per  task 
basis.  Each  capabihty  specifies  the  right  to  either  receive  from  or  send  to  a  particular  port. 
These  capabilities  may  be  transferred  to  another  task  by  sending  a  message.  For  each  port, 
there  is  exactly  one  receive  capability  and  therefore  at  most  one  task  can  receive  frnm  the  port 
(no  task  is  able  to  receive  from  a  port  for  which  the  receive  capabihty  is  in  transit  rather  than 
in  an  IPC  name  space).  IPC  is  asynchronous  in  that  messages  are  queued  in  the  port  and 
the  sending  task  does  not  wait  until  its  message  has  been  received  (an  exception  is  when  the 
microkernel  is  the  receiving  task,  in  which  case  the  sender  waits  until  the  microkernel  finishes 
processing  the  message). 

Sending  or  receiving  a  message  is  a  Mach  microkernel  operation  to  which  DTOS  has  added 
security  controls  that  enforce  the  security  pohcy.  Thus,  piossession  of  the  appropriate  capabiht\’ 
for  a  port  is  necessary  but  not  sufficient  in  order  to  se^  or  receive  a  message  frnm  that  port. 
The  security  contexts  of  the  task  and  the  port  must  also  permit  the  operation  The  policy  also 
constrains  what  capabilities  may  be  passed  in  a  message  sent  or  received  by  a  task. 

The  Security  Server  receives  requests  frnm  the  microkernel  through  the  microkernel  security 
port  and  frem  other  servers  through  a  general  security  port.  Requests  contain  an  operation 
identifier  (allowing  the  Security  Server  to  record  which  permissions  have  been  requested  in 
support  of  history-based  policies  that  depend  on  the  sequence  of  operations  made  on  an  object), 
a  subject  security  identifier  SSI  (representing  the  security  context  of  the  subject),  an  object 
security  identifier  OSI  (representing  the  security  context  of  the  object),  and  a  send  capabilitj’ 
for  a  reply  port.  The  Security  Server  replies  by  sending  the  permissions  for  that  pair  to 
the  reply  port  (Figure  A-21).  Not  shown  in  this  figure  is  the  fact  that  the  Security  Server 


Figure  A-21:  Security  Server  Interaction 

both  defines  and  enforces  a  policy  for  the  requests  that  it  receives.  It  might  allow  security- 
determination  requests  fix>m  some  subjects,  but  not  frnm  others.  Similarly,  it  might  allow 
security  determination  requests  firom  a  particular  subject  only  for  certain  (SSI,OSI)  pairs. 

Security  enforcement  as  described  above  would  be  very  expensive  due  to  the  large  number 
of  messages  that  must  be  exchanged  between  the  microkernel  and  the  Security  Server.  The 
solution  in  DTOS  is  to  cache  (SSI, OSI)  pairs  with  their  permissions  in  the  microkernel  [16]. 
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\Mien  the  microkernel  receives  a  request,  it  first  looks  in  tlie  cache  for  the  appropriate  (SSl.OSI  ■ 
pair.  If  that  pair  is  in  the  cache,  the  microkernel  uses  the  cached  entries.  Otherwise,  it  sends 
the  pair  to  the  Security  Server  to  determine  the  permissions,  usually  also  caching  the  reply 
(part  of  the  permission  set  returned  is  permission  to  cache  the  reply  —  caching  would  not  be 
permitted  for  permissions  granted  for  a  single  operation  by  a  dynamic  policy).  Since  sending  to 
and  receiving  from  a  port  are  microkernel  operations  controlled  by  the  policy,  the  cache  must 
be  preloaded  with  permission  for  the  Secuiitj-  Server  to  send  and  receive  from  the  designated 
ports. 

In  order  to  implement  a  different  policy,  either  by  changing  the  current  Security  Server  or  by 
referring  to  a  new  Security  Server,  there  must  be  a  mechanism  for  flushing  permissions  from 
the  microkernel’s  cache.  Otherwise,  if  the  new  policy  removes  pennissions  from  the  system 
for  a  specific  (SSI,  OSI)  pair,  and  the  microkernel  has  already  cached  the  jiermissions  for  that 
pair,  then  the  microkernel  would  continue  to  enforce  the  old  pohcy  rather  than  consult  the 
Sectuity  Server  defining  the  new  policy.  Therefore,  the  Security  Server  may  issue  a  command 
to  the  microkernel,  and  any  other  servers  registered  as  caching  permissions  determined  by 
the  Security  Server,  telling  it  to  flush  its  cache.  However,  it  would  be  impractical  for  the 
microkernel  to  flush  eveiy  p>ermission  in  its  cache;  for  if  it  did,  the  entire  system  would  come  to 
a  halt.  Therefore,  some  pennissions  are  hard-coded.  These  include  some  of  the  basic  permission 
required  for  IPC  between  the  subjects  comprising  the  operating  system  itseff. 

The  separation  between  pohcy  and  enforcement  in  the  DTOS  prototype  made  it  attractive  for 
studying  adaptive  security.  The  work  described  in  this  report  discusses  refinements  to  the 
design  that  are  important  for  these  pohcies. 
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